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CAPÍTULO 1 


Liderar ou sangrar? 


Se vocé vai investir seu dinheiro, muitas opgöes estáo disponiveis. Vocé pode investi- 
lo em uma poupanga, apesar de que o rendimento possivelmente náo seja táo van- 
tajoso se comparado com a inflação. Ou você pode investi-lo em títulos do governo. 
Novamente, vocé pode náo ganhar tanto dinheiro, mas sáo apostas seguras. 

Ou ainda, vocé pode investir em uma pequena startup. Vocé pode, por exemplo, 
investir algum dinheiro em troca de uma pequena parte na sociedade da empresa. Se 
a ideia da empresa for boa e ela puder executá-la, vocé pode potencialmente ganhar 
bastante dinheiro. Por outro lado, náo é nem garantido que vocé vá recuperar seu 
investimento. 

Esse conceito náo é novo. Vocé comeca a aprendé-lo como uma crianga brin- 
cando. Se eu correr por aqui, eu vou surpreender todo mundo e náo vou ser pego. 
Vocé é lembrado disso com bastante frequéncia no seu cotidiano. Vocé passa pelo 
trade-off risco-recompensa quando está atrasado para uma reuniáo e precisa esco- 
lher o melhor caminho para o trabalho. Se o tránsito não estiver ruim, eu posso 
chegar lá 15 minutos mais rápido se eu for por esse caminho. Mas se tiver tránsito, 
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estou ferrado. 

O trade-off risco-recompensa é uma parte importante do processo de fazer esco- 
lhas intencionais sobre em quais tecnologias e dominios investir. Quinze anos atrás, 
uma escolha de baixo risco seria aprender a programar em COBOL. Claro, também 
havia tantos programadores COBOL com quem concorrer, que o salário médio nessa 
época já não era fenomenal. Você podia facilmente encontrar trabalho, mas não seria 
algo tão lucrativo. Baixo risco. Baixa recompensa. 

Por outro lado, se âquela época você tivesse decidido investigar a nova linguagem 
de programação da Sun Microsystems, o Java, durante um tempo talvez fosse difícil 
encontrar emprego em algum lugar que estivesse usando essa linguagem. Quem iria 
saber se alguém realmente faria algo em Java? 

Mas se você estivesse de olho em como estava a indústria naquela época, da 
forma como a Sun estava, você poderia ter visto algo especial no Java. Poderia ter 
sentido que aquilo se tornaria grande. Investir naquela tecnologia logo no início faria 
de você um líder em uma grande e influente tecnologia. 

É claro, nesse caso você teria se dado bem. E se tivesse jogado suas cartas cor- 
retamente, seu investimento em Java teria sido muito lucrativo. Alto risco. Alta re- 
compensa. 

Agora, imagine que também há 15 anos você tenha visto uma demonstração do 
novo BeOS, da Be. Na época ele era incrível. Ele foi construído para tirar vantagem 
de múltiplos processadores. Suas capacidades de multimídia eram impressionantes. 
A plataforma fez bastante barulho na época e os especialistas sentiam que estava ali 
um novo concorrente fortíssimo no mercado de sistemas operacionais. 

Com a nova plataforma, claro, viriam novas maneiras de programar, novas APIs, 
novos conceitos de interfaces com o usuário. Era muita coisa para se aprender, mas 
parecia valer bastante a pena. Você poderia ter criado o primeiro cliente de FTP ouo 
primeiro gerenciador de informações para o BeOS. Quando a Be lançou uma versão 
compatível com processadores Intel, rumores indicavam que a Apple a compraria a 
empresa para usar sua tecnologia na próxima geração do sistema operacional Ma- 
cintosh. 

A Apple não comprou a Be. E após algum tempo, ficou claro que a Be não iria 
conseguir nem sequer um mercado de nicho. O produto simplesmente não pegou. 
Muitos desenvolvedores que dominaram programação para o BeOS começaram a 
perceber que aquele investimento não se pagaria no longo prazo. Após algum tempo, 
a Be foi comprada pela Palm e o sistema operacional foi descontinuado. BeOS era 
um investimento arriscado, porém atrativo, que não deu retorno a longo prazo. Alto 
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risco. Nenhuma recompensa. 

Até aqui, eu falei sobre a diferenga entre escolher tecnologias que ainda sáo re- 
centes e as que já estáo estabelecidas. Escolher uma tecnologia estável e que já está 
em produção em diversos sistemas é uma escolha mais segura, no entanto, com re- 
compensa potencialmente menor do que uma tecnologia que poucos conhecem e 
que ninguém sabe como colocar em produgäo. Mas e as tecnologias que já estáo 
saindo de cena? Aquelas que já estáo apenas esperando para serem enterradas? 

Quem dará fim nessas tecnologias? Vocé pode pensar nos últimos poucos pro- 
gramadores que desenvolvem em RPG como sendo aqueles caras de cabelos grisa- 
lhos e contando as horas até a aposentadoria, enquanto os jovens desenvolvedores 
nunca ouviram falar de RPG. Eles estão todos aprendendo Java e NET. É fácil pensar 
que a carreira dos últimos sobreviventes de uma velha e decadente tecnologia estáo 
na mesma espiral da morte que a própria tecnologia. 

Mas sistemas antigos náo morrem simplesmente. Eles sáo substituídos. Além 
disso, na maioria dos casos, sistemas caseiros sáo substituidos em estágios. Nesses 
estágios, o sistema antigo precisa conversar com o novo. Alguém precisa fazer o novo 
falar com o antigo e vice-versa. Usualmente, as crianças rebeldes não sabem (ou 
não querem saber) como fazer o sistema antigo escutar. E nem os mais velhos pré- 
aposentadoria sabem como fazer as novidades conversarem com sua amada criatura. 


As duas pontas da curva de adoção devem provar serem lucrativas. 


Então, há um papel a ser preenchido pelos desenvolvedores: o asilo da tecno- 
logia. Ajudar antigos sistemas a morrer confortavelmente e com dignidade é algo 
que não deve ser subestimado. E lógico, a maioria das pessoas irá pular do barco 
antes que ele afunde, seja via aposentadoria ou indo para outra tecnologia. Sendo 
o último que sobrou para manter os sistemas que ainda são críticos, você é o cara. 
É arriscado, já que, uma vez que a tecnologia já era, você será especialista em algo 
que não existe. No entanto, se você puder se mover rápido o suficiente, você pode 
procurar a próxima geração de sistemas que estão morrendo e começar novamente. 

A curva de adoção tem altas nas duas pontas. Onde nessas curvas você quer 
estar? 


Faça algo 
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1) Faga uma lista de tecnologias recentes, médias e antigas baseada no mercado 
atual. Mapeie-as em uma folha da esquerda para a direita. Na esquerda, colo- 
que as tecnologias recentes, e na direita, as que estáo próximas do fim. Force a si 
mesmo para encontrar a maior quantidade possível de tecnologias. Seja o mais 
granular possível sobre onde as tecnologias estáo quando comparadas umas com 
as outras. 


Quando você tiver mapeado o máximo de tecnologias que conseguiu se lembrar, 
marque as tecnologias nas quais você se considera forte. Então, talvez em uma 
cor diferente, marque aquelas sobre as quais você possui algum conhecimento, 
mas não domina. Onde está a maioria das tecnologias que você marcou? Elas 
estão aglomeradas em alguma ponta? Estão espalhadas? Elas estão próximas às 
pontas em que você se interessa? 


CAPÍTULO 2 


Oferta e demanda 


Quando a Web realmente comegou a decolar, era possível ganhar bastante dinheiro 
simplesmente criando páginas HTML para empresas. Toda empresa queria uma pá- 
gina web e relativamente poucas pessoas sabiam como fazé-las. Empresas estavam 
dispostas a pagar bem para web designers “experientes”, o que naquela época signi- 
ficava dizer que conheciam o básico de HTML, criagáo de links e estrutura de sites. 

Fazer HTMLs é muito simples. Difícil é fazer páginas que sejam visualmente 
bonitas, mas o básico é fácil de atingir. Conforme as pessoas perceberam os valores 
cobrados por esses web designers, mais e mais pessoas começaram a pegar livros 
de HTML e aprender a tecnologia por conta própria. O mercado estava quente, os 
salários ou valores por hora eram atraentes, e como resposta, a oferta de especialistas 
em HTML começou a aumentar. 

Conforme o mercado foi inundado de web designers, o pessoal de web começou 
a ser classificado entre reais artistas, que dominavam a tecnologia e possuíam grande 
habilidade, e os práticos, que náo tinham a mesma qualidade e competéncia dos 
reais artistas. Além disso, a concorréncia acabou levando a queda dos pregos. Como 
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um resultado dos preços mais baixos, mais empresas estavam dispostas a dar seu 
primeiro passo em direção à presença na internet. Eles não pagariam $5.000 por seu 
primeiro site, mas sim $500. 

Claro, algumas empresas ainda estavam dispostas a pagar bastante dinheiro por 
um site “fantástico”. E certamente os web designers ainda conseguiam cobrar valores 
“fantásticos”. 

Em um determinado momento, a inundação de web designers de médio e baixo 
custo regrediu. Web designers menos talentosos foram substituídos por usuários 
finais e outro pessoal de TI que náo necessariamente dominava HTML. Nesse ponto, 
a oferta, demanda, e o preco de desenvolvimento chegou a um equilibrio. 

Essa história sobre a evolução do web design mostra um modelo econômico de 
que todos nós já ouvimos falar, chamado oferta e demanda. Quando a maioria de 
nós pensa em oferta e demanda, achamos que tem a ver com o prego com que algo 
pode e será vendido. Se houver mais de um item à venda do que o número de pessoas 
querendo comprar aquele produto, então seu preço vai diminuir. Se houver mais 
pessoas querendo comprar o produto do que a quantidade de produtos disponíveis, 
o preço irá aumentar, de forma que os compradores concorram entre si. 

Além de prever o preço de bens e serviços, o modelo de oferta e demanda pode 
prever como as mudanças de preço irão afetar os que querem comprar e vender os 
produtos e serviços. Geralmente há mais compradores para um produto barato do 
que para um mais caro. 


Você não pode competir em preço. Na verdade, você não consegue competir em preço. 


Por que isso é importante para nós? A tendência de fazer software offshore acaba 
de injetar uma grande oferta de pessoas de TI de baixo custo em nossa economia. 
Embora estejamos preocupados em perder empregos, o custo mais baixo por progra- 
mador na verdade aumentou a demanda. Ao mesmo tempo, conforme a demanda 
aumenta, os preços diminuem. Concorrência em produtos e serviços com alta de- 
manda acaba por movimentar também os preços. No mercado de empregos, isso 
significa salários. Você não pode competir em preço. Você não consegue. Então, o 
que fazer? 

O mercado de desenvolvimento offshore injetou seus programadores de baixo 
custo em um conjunto relativamente pequeno de tecnologias. Programadores Java e 
.NET são baratos e existem aos montes na Índia, junto dos DBAs Oracle. Tecnologias 
menos populares são pouco adotadas pelas empresas de offshore. Durante a escolha 
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de um conjunto de tecnologias para focar em sua carreira, vocé deve entender os 
efeitos da oferta crescente e menores preços. 

Como um desenvolvedor .NET, vocé deve se encontrar concorrendo com mais 
dezenas de milhares de pessoas do que, por exemplo, um desenvolvedor Python. 
Isso resultaria no custo médio de um desenvolvedor .NET reduzindo significativa- 
mente, possivelmente aumentando a demanda (nesse caso, criando mais empregos 
em .NET). Com isso, vocé encontraria emprego, mas que náo pagaria táo bem. A 
oferta de programadores Python deve ser bem menor que a de .NET para suportar 
a demanda. 

Se o mercado de trabalho em Python estivesse pagando valores mais altos por 
programador, as pessoas ficariam atraídas por oferecer seus serviços por esses valo- 
res, resultando em concorrência, o que levaria os preços para baixo novamente. 

É tudo uma questão de balanceamento. Mas uma coisa parece certa (por en- 
quanto). A Índia provê programadores para os mercados de TI que já estão balance- 
ados. Você não encontra empresas de offshore indianas e famosas utilizando tecno- 
logias não convencionais. Eles não são pioneiros. Eles geralmente não se arriscam. 
Eles esperam o mercado balancear para então entrarem nesse mercado com valores 
por programador significativamente mais baratos. 

Com base nessa observação, você deve escolher competir em segmentos do mer- 
cado em que há menor demanda. Por mais contraintuitivo que possa parecer, se você 
está preocupado em perder seu emprego para o offshore, uma estratégia seria evitar 
os tipos de trabalho que as empresas de offshore estão fazendo. Elas estão fazendo 
trabalhos com alta demanda. Então, focar em tecnologias de nicho é uma estratégia 
que, embora não necessariamente torne a competição menos feroz (há menos em- 
pregos para ir atrás), muda o foco da concorrência de preço para habilidade. É isso 
o que você precisa. Você não pode competir em preço, mas você pode competir em 
habilidade. 

Além disso, com o preço médio dos programadores de tecnologias mainstream 
em queda, a demanda irá crescer. Um aumento geral nessa demanda por programa- 
dores Java, por exemplo, pode resultar em mais empregos no seu país, não menos. 
Um aumento no mercado de offshore, que é barato, pode influenciar na demanda. 

Isso acontece na prática. Para que o offshore funcione bem, muitas empresas 
percebem a necessidade de manter uma quantidade de desenvolvedores de alto nível, 
que definam os padrões da empresa, garantam a qualidade e provenham liderança 
tecnológica. Um aumento na demanda por programadores Java iria naturalmente 
elevar demanda nessa categoria de trabalho. Os trabalhos mais baratos podem estar 
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indo para o offshore, mas há mais trabalhos de alto nível, ou de elite, do que ha- 
via antes da época do offshore. Como vimos nos mercados de nicho, a competição 
mudaria de preco para habilidade. 


Explore mercados náo balanceados. 


A ligáo mais importante que podemos levar do modelo de oferta e demanda é 
que com o aumento da demanda vem o aumento da concorrência de preço. Seguir 
esse caminho o levará a concorrer em preço com desenvolvedores offshore, pois suas 
habilidades irão se encaixar nos mercados balanceados em que o offshore atua. Para 
competir em tecnologias mainstream, você terá que enfrentar um nível mais alto. 
Alternativamente, você pode explorar mercados não balanceados, aonde as empresas 
de offshore não vão. Em ambos os casos é imprescindível entender as forças que estão 
em jogo e ser habilidoso e ágil o suficiente para reagir a elas. 


Faça algo 


1) Pesquise a demanda por habilidades técnicas. Use sites de vagas de trabalho e 
carreiras para encontrar quais habilidades estão em alta e em baixa demanda. 
Ache os sites de empresas de offshore (ou fale com funcionários dessas empresas). 
Compare as habilidades usadas nessas empresas com a lista que tecnologias em 
alta demanda que você fez. Anote as tecnologias às quais você vê que há uma boa 
demanda, mas que empresas de offshore não usam. 


Faça uma comparação similar entre tecnologias recentes e as habilidades pedidas 
por empresas de offshore. Fique de olho em ambos os conjuntos de habilidades 
técnicas que não são usadas pelas empresas de offshore. Quanto tempo levará 
para que elas preencham esse buraco? Esse tempo é a janela na qual há um mer- 
cado não balanceado. 


CAPÍTULO 3 


Escrever código náo é suficiente 


Náo é suficiente pensar em quais tecnologias vocé vai investir. Afinal, a parte de tec- 
nologia é um bem, certo? Vocé náo vai ser capaz de sentar e simplesmente dominar 
uma linguagem de programagäo ou um sistema operacional, permitindo que as pes- 
soas de negócios cuidem da parte de negócios. Se tudo o que eles precisavam era de 
um robó de código, seria fácil contratar alguém de outro país para fazer esse traba- 
lho. Se você quer permanecer relevante, vai ter que ir fundo no dominio do negócio 
dentro do qual vocé está. 

Na verdade, uma pessoa de software deve compreender um dominio náo apenas 
bem o suficiente para desenvolver software para ele, mas também para se tornar uma 
de suas referéncias. Em uma empresa onde trabalhei, vi um excelente exemplo disso. 
A equipe de administragäo de banco de dados consistia de pessoas que realmente náo 
estavam interessadas em tecnologia de banco de dados. Quando eu as encontrei pela 
primeira vez, foi um choque. Por que essas pessoas trabalham com tecnologia? Eu 
me perguntava. Em termos de habilidade técnica, eles náo eram bons. Mas este time 
tinha algo especial. Sendo os guardióes e protetores de dados de nossa empresa, eles 
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conheciam o domínio do negócio melhor do que quase qualquer analista de negócios 
que tinhamos. Seus conhecimentos e compreensáo do negócio os tornaram figuras 
importantes nesse mercado. Enquanto nós, geeks, estávamos olhando para eles com 
desdém, o “negócio” para o qual eles trabalhavam via um enorme valor neles. 

Vocé deve pensar em sua experiéncia de domínio do negócio como uma parte 
importante do seu repertório. Se vocé é um músico, quando adicionar algo ao seu 
repertório, náo significa apenas que vocé tocou a música uma vez. Significa que vocé 
realmente conhece a música. A mesma teoria deve ser aplicada á sua experiéncia de 
domínio. Por exemplo, depois de ter trabalhado em um projeto no setor de seguros 
de saúde, isso náo garante que vocé entenda a diferenga entre uma transagäo HI- 
PAA 835 e uma HIPAA EDI 837. É esse tipo de conhecimento que diferencia dois 
desenvolvedores trabalhando nessa problema. 

Vocé pode ser “apenas um programador”, mas ser capaz de falar com seus clien- 
tes do negócio na língua de seu dominio de negöcio € uma habilidade única. Imagine 
o quanto a vida seria mais fácil se todo mundo com que vocé tivesse que trabalhar 
realmente entendesse como funciona desenvolvimento de software. Náo seria neces- 
sário explicar a eles por que é uma má ideia devolver 30000 registros em uma única 
página em uma aplicação web ou por que eles não compartilham o endereço para 
seu servidor de desenvolvimento. Esta é a forma como os seus clientes de negócios 
se sentem em relação a você: Imagine o quão mais fácil seria trabalhar com esses 
programadores, se eles entendessem o que eu estava pedindo, sem que eu tivesse 
que explicar tudo de forma tão burra e tão detalhista! E, adivinhem? É a empresa 
que paga o seu salário. 

Assim como as tecnologias se destacam, domínios podem ser escolhidos da 
mesma forma. Java e .NET são agora mainstream no desenvolvimento de software. 
Se você aprender essas linguagens, poderá concorrer a um emprego em uma das 
muitas empresas que utilizam estas tecnologias. O mesmo é verdade para os domi- 
nios. Ao escolher em qual indústria trabalhar, você deve ter o mesmo cuidado que 
teve ao decidir quais tecnologias dominar. 


Agora é hora de pensar nos domínios em que você investe seu tempo. 


Além da importância que se deve dar ao escolher um domínio ao montar seu 
portfólio, a empresa e indústria em que você escolher trabalhar se tornam um inves- 
timento significativo em si próprio. Se você ainda não tiver parado para pensar em 
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quais dominios deveria investir, agora é a hora. Cada dia que passa € uma oportuni- 


dade perdida. Da mesma forma que deixar suas economias em uma conta poupança 


de baixo rendimento, enquanto é possível conseguir taxas de juros mais altas, deixar 


o seu desenvolvimento em negócios parado é uma péssima escolha de investimento. 


Faça algo 


1) 


2) 


Agende um almoço com um empresário. Converse sobre como eles trabalham. 
Durante a conversa, pergunte a si mesmo o que você teria que mudar ou aprender 
se quisesse ter o trabalho dele. Pergunte sobre as especificidades do seu trabalho. 
Converse sobre como tecnologia os ajudam (ou atrapalham). Pense no seu tra- 
balho a partir da perspectiva deles. 


Faça isso regularmente. 


Isso pode parecer uma ideia estranha ou desconfortável. Tudo bem. Eu comecei 
a fazer isso há muitos anos e isso fez uma grande diferença na forma como eu 
entendia e me relacionava com o negócio no qual eu estava trabalhando. Eu tam- 
bém me senti mais confortável falando com os meus clientes, o que é um efeito 


colateral positivo. 


Pegue uma revista especializada na indústria de sua empresa. Provavelmente você 
não terá nem sequer que comprá-la. A maioria das empresas tem essas revistas 
espalhadas em algum lugar. Comece a lê-la. Provavelmente você não irá entender 
tudo o que lê, mas seja persistente. Faça listas de perguntas que você pode fazer a 
seus gerentes ou clientes. Mesmo que suas perguntas lhe pareçam estúpidas, seus 
clientes vão perceber que você está tentando aprender. 


Procure sites que você possa monitorar de forma regular. Tanto nos sites como 
nas revistas, preste atenção ao assunto das grandes notícias e dos artigos. Quais 
são os problemas que a indústria está tentando resolver? Qual é o novo assunto 
dominante? Seja o que for, converse sobre isso com seus clientes. Peça para eles 
lhe explicarem e darem suas opiniões. Pense em como essas tendências atuais 
afetarão sua empresa, sua área, sua equipe, e eventualmente, o seu trabalho. 
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CAPÍTULO 4 


Seja o pior 


Pat Metheny, lendário guitarrista de jazz, costuma dar um conselho para jovens mú- 
sicos: “Sempre seja o pior cara da banda em que você estiver”. 

Antes de iniciar minha carreira em TI, eu tocava jazz e saxofone profissional- 
mente. Como músico, eu tive a sorte de aprender esta lição bem cedo. Ser o pior 
cara da banda significa sempre tocar com pessoas que sáo melhores do que vocé. 


Seja o pior em qualquer grupo em que estiver. 


Agora, por que vocé escolheria ser a pior pessoa em uma banda? “Isso náo é 
irritante?”, vocé se pergunta. Sim, é extremamente irritante, no comego. Como um 
jovem músico, eu me via em situações em que ficava tão óbvio que eu era o pior cara 
da banda, que eu tinha certeza que iria ficar de fora. Eu apareceria para o show mas 
nem pegaria meu sax, com medo de ser expulso da apresentação. Eu estava perto de 
pessoas as quais antes eu observava e em cujo nível esperava tocar, às vezes como o 
instrumento principal. 
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Sem falhar (felizmente!), algo mágico acontecia: eu me encaixava no grupo. E 
náo me destacava como uma estrela entre os outros músicos. Mas por outro lado, eu 
náo era, também, deixado de lado. Isto acontecia por duas razóes. A primeira é que 
eu náo era táo ruim quanto eu pensava. Vou falar disso depois. 

A razáo mais interessante pela qual eu me encaixava com estes caras táo bons, 
alguns até meus heróis, é que minha música se parecia com a deles. Eu achava que eu 
tinha algum tipo de super poder de me transformar em um génio simplesmente por 
estar ao lado de algum deles, mas na verdade, é algo bem menos interessante que isso. 
Era um comportamento instintivo, programado em mim. É o mesmo fenómeno que 
faz com que eu fale mais difícil, use um diferente vocabulário ou hábitos gramaticais 
quando estou perto de pessoas que falam de forma diferente. Quando voltamos da 
Índia, após viver um ano e meio por lá, minha esposa, ás vezes, me ouvia falando e 
morria de rir. “Vocé ouviu o que vocé disse?” — eu estava falando inglés indiano. 

Ser o pior cara da banda trouxe o mesmo comportamento em mim como um 
saxofonista. Naturalmente eu tocava como os outros. O que torna esse fenómeno 
realmente sem glamour é que quando eu tocava em cassinos e bares com bandas 
náo táo boas, eu tocava mal como eles. Além disso, meio que naturalmente eu via 
os maus hábitos das bandas sendo levados por mim para as noites nas quais eu náo 
tocava com eles. 

Com isso, eu aprendi que as pessoas podem melhorar ou piorar em habilidade, 
apenas levando em conta com quem elas estáo trabalhando. E ficar em um grupo 
por muito tempo pode impactar na capacidade da pessoa. 


As pessoas ao seu redor afetam a sua performance. Escolha bem seu grupo. 


Mais tarde, conforme eu me mudei para a indústria de tecnologia, percebi que o 
hábito de procurar os melhores músicos era natural para mim como um programa- 
dor. Talvez inconscientemente eu procurei trabalhar com as melhores pessoas de TI. 
E, náo surpreendentemente, essa ligáo é verdade. Ser o pior cara (ou garota, é claro) 
na equipe tem o mesmo efeito de ser o pior cara da banda. Vocé acha que é inex- 
plicavelmente mais inteligente. Vocé pode até mesmo falar e escrever de forma mais 
inteligente. Seus códigos ficam mais elegantes e vocé acredita ser capaz de resolver 
problemas difíceis com solugöes cada vez mais criativas. 

Vamos voltar para a primeira razáo pela qual eu fui capaz de me integrar a es- 
sas bandas melhor do que eu esperava. Eu realmente náo era táo ruim quanto eu 
pensava. Na música, é muito fácil medir se os outros músicos pensam que vocé é 
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bom. Se vocé é bom, eles o convidam para tocar com eles novamente. Se vocé náo 
for bom, eles o evitam. É uma medida muito mais confiável do que apenas perguntar 
o que eles pensam, porque bons músicos náo gostam de tocar com músicos ruins. 
Para minha surpresa, eu percebi que, em muitos desses casos, eu era telefonado por 
um ou mais desses músicos superiores para algum trabalho adicional ou até mesmo 
para comegar bandas com eles. 

Tentar ser o pior faz com que vocé pare de se vender por táo pouco. Vocé pode 
pertencer á banda A, mas sempre se coloca na banda B, pois está com medo. Re- 
conhecer abertamente que vocé náo é o melhor tira o medo de vocé ser descoberto 
da forma que vocé náo gostaria. Na verdade, mesmo quando vocé tentar ser o pior, 


vocé náo será. 


Faca algo 


1) Encontre uma situação para você ser o pior. Você pode não se dar ao luxo de 
mudar de equipe ou até mesmo de empresa só porque quer trabalhar com pessoas 
melhores. Em vez disso, encontre um projeto para trabalhar como voluntário em 
que vocé possa trabalhar com outros desenvolvedores, que iráo torná-lo melhor 
por osmose. Veja se há encontros de grupos de desenvolvedores em sua cidade 
e participe dessas reunióes. Desenvolvedores estáo frequentemente procurando 
por projetos para ocupar seu tempo livre, praticar novas técnicas e aprimorar suas 


habilidades. 


Se náo há uma comunidade ativa perto de vocé, use a internet. Escolha um pro- 
jeto open source de que vocé goste e cujos desenvolvedores parecem estar em um 
nivel acima do seu. Vá até a lista de tarefas do projeto ou o histórico da lista de 
discussão, escolha uma funcionalidade ou uma correção de bug importante e es- 
creva o código! Imite o estilo de código do projeto. Faça disso um jogo. Faça o 
seu código de forma que ele seja indistinguível do restante do projeto, de modo 
que até mesmo os desenvolvedores originais não saibam quem escreveu. Então, 
quando você estiver satisfeito com o seu trabalho, submeta suas modificações. Se 
for bom, vai ser aceito no projeto. Comece de novo e faça novamente. Se você 
tomou decisões das quais os desenvolvedores do projeto discordam, pegue o feed- 
back deles, use-o para melhorar seu código e envie novamente as modificações. 
Se eles modificarem seu código, tome nota das alterações que fizeram. Em seu 
próximo patch, tente fazer com que ele seja aceito com menos retrabalho. Even- 
tualmente, você vai perceber que irá se tornar alguém de confiança da equipe do 
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projeto. Vocé vai se surpreender com o que se pode aprender a partir de um con- 
junto remoto de desenvolvedores seniores, mesmo se vocé nunca teve a chance 
de ouvir suas vozes. 


CAPÍTULO 5 


Invista em sua inteligéncia 


Quando escolher em que focar, pode ser tentador simplesmente olhar para as tec- 
nologias que geram mais empregos e concentrar-se nelas. Java é grande. .NET é 
grande. Aprender Java tem um efeito simples, transitivo: se eu sei Java, eu posso me 
candidatar, e possivelmente, conseguir um trabalho onde vou escrever código Java. 

Usando essa lógica, seria insensato escolher investir em um nicho de tecnologia, 
especialmente se vocé náo tem intengäo de tentar explorá-lo. 

O TIOBE, http://www.tiobe.com, usa os sites de busca da internet para identi- 
ficar a popularidade de linguagens de programação, com base em pessoas falando 
sobre as linguagens. Segundo o TIOBE, “Os números sáo baseados na disponibili- 
dade mundial de engenheiros qualificados, cursos e fornecedores”. Definitivamente 
náo é uma medida cientifica de popularidade, mas náo deixa de ser um bom indica- 
dor. 

No momento da escrita desse livro, a linguagem mais popular é o Java, seguido 
por C. C# está em um respeitável sexto lugar, mas com uma trajetória levemente na 
ascendente. ABAP está em décimo sétimo lugar e está caindo lentamente. Ruby, que 
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€ a minha linguagem favorita — na qual eu fago praticamente todo o meu trabalho 
sério e aquele para o qual eu co-organizo uma conferéncia internacional a cada ano 
— está em décimo primeiro lugar. E no momento em que a primeira edição deste 
livro foi publicada, ela náo ficou nem entre os top vinte. Ficou abaixo de ABAP! 

Por que Ruby? Eu estava louco ou fui burro? Deve ser um dos dois, certo? 

Em seu trabalho chamado “Grandes Hackers” — http://paulgraham.com/gh. 
html, Paul Graham deixou a comunidade de desenvolvedores irritadíssima com a 
afirmação de que os programadores Java nao eram tão espertos quanto quem pro- 
gramava em Python. Ele deixou bravo um monte de programadores Java burros (eu 
disse isso?), fazendo com que vários deles escrevessem respostas a ele em seus sites. 
A reacáo violenta indica que ele atingiu algo. Eu estava na plateia quando seu tra- 
balho foi apresentado pela primeira vez, na forma de um discurso. Ele causou um 
flashback em mim. 

Eu estava em uma viagem de recrutamento na Índia, no meio de centenas de 
candidatos para dezenas de vagas, e a equipe de entrevistadores estava cansada e 
ficando sem tempo por conta do baixo índice de entrevistas bem sucedidas, que re- 
sultassem em contratações. Com dores de cabeça e olhos vermelhos, fizemos uma 
reunião tarde da noite para discutir uma mudança estratégica na forma como iría- 
mos abordar os candidatos. Nos tinhamos que otimizar o processo para que pudés- 
semos entrevistar mais pessoas ou de alguma forma entrevistar pessoas melhores (ou 
ambos). Com o pouco que restava da minha voz depois de doze horas seguidas de 
tentar arrancar respostas de programadores mudos, eu pedi para adicionar Smalltalk 
para a lista de palavras-chave que nossos headhunters estavam usando para procurar 
no banco de dados de currículos. “Mas ninguém sabe Smalltalk na Índia”, gritou o 
diretor de recursos humanos. Esse foi o meu ponto. Ninguém sabia, e programar 
em Smalltalk era uma experiência diferente de programar em Java. A mudança da 
experiência daria aos candidatos um nível diferente de expectativas, e a natureza di- 
nâmica de Smalltalk levaria a uma outra maneira com a qual um programador Java 
iria abordar um problema. Minha esperança era que esses fatores encorajassem um 
nível de maturidade técnica que eu não tinha visto dentre os candidatos que eu co- 
nhecia até então. 

A adição de Smalltalk para a lista de requisitos rendeu um grupo de candidatos 
que era pequeno se comparado com nossa lista anterior. Essas pessoas eram diaman- 
tes brutos. Elas realmente aprenderam programação orientada a objetos. Estavam 
cientes de que o Java não era a loucura idealista como às vezes era pintada. Mui- 
tos deles amavam programar! "Onde você esteve nas últimas duas semanas?”, nós 
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pensávamos. 

Infelizmente, a nossa capacidade de atrair esses desenvolvedores, com os salários 
que éramos capazes de pagar, era limitada. Eles ditavam o tom, e a maioria deles pre- 
feriu ficar onde estava ou continuou procurando um novo emprego. Apesar de náo 
conseguirmos recrutar muitos deles, aprendemos uma ligáo valiosa de recrutamento: 
nós estávamos mais propensos a fazer propostas para candidatos com experiéncias 
diversas (e até mesmo pouco ortodoxas) do que para aqueles cuja experiéncia era 
homogénea. Minha explicação é que, ou as pessoas boas buscam a diversidade, pois 
elas amam aprender coisas novas, ou ser forçado em experiências e ambientes mais 
exóticos criava programadores mais maduros e preparados. Eu acredito que seja um 
pouco dos dois, mas, independentemente do motivo pelo qual ele funciona, a gente 
descobriu que isso funciona. Eu continuo usando esta técnica quando procuro de- 
senvolvedores. 

Entáo, ao invés de tentar simplesmente aparecer na minha frente quando eu esti- 
ver á procura de alguém para contratar, por que vocé náo vai investir em tecnologias 
em que vocé raramente terá a chance de ser pago para trabalhar? 

Para mim, como um gerente de contratacäo, a primeira razáo € que isso mostra 
que vocé está interessado. Se eu sei que vocé aprendeu alguma coisa por causa do 
autodesenvolvimento e (melhor ainda) pura diversáo, eu sei que vocé está animado 
e motivado sobre a sua profissáo. Fico muito irritado quando pergunto ás pessoas se 
elas já viram ou usaram algumas tecnologias não tradicionais e ouço como resposta: 
“não me deram a oportunidade de trabalhar com isso”. Não lhe deram oportunidade? 
Pra mim também não! Eu fiz a oportunidade para aprender. 


Não lhe deram a oportunidade...? Faça a oportunidade! 


Mais importante do que retratar a percepção de que se está devidamente moti- 
vado e engajado em sua área é que a exposição a essas tecnologias e metodologias 
não tradicionais lhe traz mais profundidade e o torna melhor, mais inteligente e mais 
criativo. 

Se essa não é uma razão suficientemente boa, então provavelmente você está na 
profissão errada. 


Faça algo 
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Aprenda uma nova linguagem de programação. Mas não vá de Java para C# ou 
de C para C++. Aprenda uma nova linguagem que o faça pensar de uma maneira 
diferente. Se você é um programador Java ou C#, tente aprender uma linguagem 
como Smalltalk ou Ruby, que não usem tipagem forte e estática. Ou, se está pro- 
gramando orientado a objetos por bastante tempo, tente uma linguagem funcio- 
nal como Haskell ou Scheme. Não precisa se tornar um especialista. Faça código 
o suficiente para que você realmente sinta a diferença de programar no novo am- 
biente. Se ela não soar estranha o suficiente, ou você escolheu a linguagem errada 
ou você está aplicando sua velha forma de pensar na nova linguagem. Peça para 
desenvolvedores mais experientes reverem o seu código e fazerem sugestões que 
o tornem idiomaticamente mais correto. 


CAPÍTULO 6 


Nao escute seus pais 


Em nossa cultura, se existe algo que é sagrado, provavelmente sáo os conselhos dados 
por nossos pais. É visto como um dever da crianga segui-los religiosamente. Livros, 
filmes e histórias de televisão formam um conjunto de ideias na cabeça de nossos 
pais. Mas para nossas carreiras no mercado de trabalho, esta ideia é errada. 

Seus pais preferem que você esteja estável ao invés de conseguir uma carreira 
notável ao custo de correr grande risco pessoal. Mais do que quaisquer outras pes- 
soas, eles vão lhe dar conselhos influenciados pelo medo. Conselhos influenciados 
pelo medo tendem ao não perder. Mas pensar em não perder não é o caminho para 
ganhar! Vencedores assumem riscos. Eles pensam sobre aonde eles querem ir, não 
onde o resto das coisas estão. Planejamento de carreira guiado pelo medo provavel- 
mente o levará a algum cubículo para o resto de sua vida, em vez de ao caminho para 
a grandeza. Claro, é seguro, mas não é divertido. 

Para as gerações anteriores, diversão não era fator decisivo quando o assunto era 
opções de carreira. Empregos não deveriam ser divertidos. Eles deveriam trazer co- 
mida pra casa. Diversão é o que você faz nos seus dias de folga. Diversão acontece 
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nas noites e fins de semana. Mas se o seu trabalho náo é divertido, como temos perce- 
bido, vocé náo o faz bem. As coisas náo sáo diferentes agora, mas nossa compreensáo 
cultural do que significa trabalhar mudou para melhor. Mais pessoas entendem que 
a paixáo leva á exceléncia. E sem diversáo, náo é provável que haja qualquer paixáo 
em um trabalho. 

Outro fator de tomada de decisáo sobre carreira, que provavelmente náo vai de 
encontro com o pensamento dos seus pais, é que náo há problema em mudar de 
emprego (na verdade, muitas vezes é preferível). Um profissional de software expe- 
riente já viu o mercado por diferentes ángulos: desenvolvimento de produto, suporte 
de TI, desenvolvimento de sistemas internos e trabalho para o governo. Quanto mais 
domínios e arquiteturas técnicas vocé já tenha visto e trabalhado, mais está prepa- 
rado para tomar as decisóes corretas em projetos mais desafiadores. Ficar em uma 
única empresa, trabalhando para subir na hierarquia, é um ambiente limitador para 
crescer como um desenvolvedor. Já foi o tempo em que as pessoas começavam sua 
carreira em uma empresa e ficavam lá mesmo até se aposentar. Este tipo de compor- 
tamento costumava ser sinal de dedicacáo. Agora é uma responsabilidade. Se vocé 
só trabalhou em um lugar e viu aquele conjunto de sistemas, muitos gerentes (inte- 
ligentes) podem ver isso como um ponto negativo contra vocé quando for decidir 
se deve contratá-lo. Eu pessoalmente prefiro contratar alguém que tenha vivenciado 
diversas situacóes de sucessos e fracassos em ambientes diferentes do que alguém 
que conhece apenas um jeito de fazer as coisas. 

Há muitos anos, eu percebi que a minha própria carreira tinha sido muito in- 
fluenciada pelos valores profissionais dos meus pais e sua geragäo. Eu trabalhei em 
uma das maiores e mais estáveis empresas do mundo e estava crescendo em um ritmo 
lento e constante. Mas eu estava estagnando. Eu ficava me dizendo que eu náo es- 
tava catando migalhas, baseando-me no fato de que a empresa era táo grande que eu 
poderia executar diferentes tarefas em uma aparente infinidade de lugares. Mas no 
final, eu ficava no mesmo lugar fazendo o mesmo tipo de trabalho. 

Eu me lembro de conversar com um amigo sobre sair da empresa, e ele disse: “É 
o seu destino trabalhar em grandes empresas para o resto da sua vida?” Claro que 
náo! Entáo, eu rapidamente encontrei outro emprego e sal. 

Este movimento marcou o início de um salto no meu sucesso na indústria de 
software. Eu vi novos domínios, trabalhei em problemas mais difíceis, e fui recom- 
pensado como nunca havia sido. Algumas vezes chegava até a ser assustador, mas 
quando eu decidi ser menos influenciado pelo medo e menos conservador nas deci- 
söes sobre minha carreira, ela acabou mudando e para melhor. 
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Assuma riscos em sua carreira. Náo deixe o medo o consumir. E se vocé náo 
estiver se divertindo, vocé náo vai ser excelente. 


Como eu abri máo de 300 mil dólares na Microsoft para trabalhar full 
time no Github 

Por Tom Preston Werner 

Em 2007 eu estava sentado sozinho em uma mesa no Zeke Sports Bar and Grill 
na 3rd Street, em San Francisco. Eu normalmente náo vou a bares de esportes, e 
muito menos a um bar de esportes em SOMA, mas aquela quinta-feira foi uma noite 
"I Can Has Ruby”. Naquela época, eu acho que "I can has _” também foi um apelido 
razoável para dar a praticamente qualquer coisa. ICHR era um encontro de hackers 
Ruby que geralmente mergulhavam em sessöes de fim de noite bebendo. Normal- 
mente as noites passavam, como a minha ressaca na manhá seguinte, mas esta noite 
foi diferente. Esta foi a noite em que nasceu o GitHub. 

Eu acho que estava sentado na mesa sozinho, porque tinha acabado de pedir 
um Fat Tire e precisava dar uma parada na socialização que estava acontecendo nas 
mesas longas e mal iluminadas do bar. No quinto ou sexto gole, Chris Wanstrath 
entrou, eu náo sei dizer se na época Chris e eu éramos amigos. Nós nos encontra- 
mos em meetups Ruby e conferéncias, mas apenas casualmente, com um mútuo “Ei, 
eu acho seu código impressionante”. Eu náo sei o que me fez fazer isso, mas eu fiz 
um sinal para ele e disse: “Cara, olha isso”. Cerca de uma semana antes, eu tinha co- 
mecado a trabalhar em um projeto chamado Grit, que permitia acessar repositórios 
Git através de código Ruby de forma orientada a objetos. Chris era um dos poucos 
rubistas na época que estava começando a levar Git a sério. Ele se sentou e eu co- 
mecei a mostrar o que eu tinha. Náo era muito, mas foi o suficiente para ver que 
tinha despertado algo em Chris. Percebendo isso, lancei um site meia-boca que fun- 
cionava como hub para programadores que queriam compartilhar seus repositórios 
Git. Eu até tinha um nome: GitHub. Posso estar parafraseando, mas sua resposta foi 
um enfático “Estou dentro! Vamos fazer isso!” 

Na noite da próxima sexta-feira, 19 de outubro de 2007, ás 22:24, Chris fez o 
primeiro commit para o repositório do GitHub, marcando o início de nossa joint 
venture. 

Até entáo, náo havia nenhum acordo sobre como as coisas iriam funcionar. Éra- 
mos apenas dois caras que decidiram hackear juntos em algo que parecia legal. 

Lembra daqueles minutos incríveis do Karate Kid em que Daniel está treinando 
para se tornar um especialista em artes marciais? Lembra da música? Bem, vocé 
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deveria ouvir, porque estou prestes alhe contar uma história. A música é You are the 
best do Joe Esposito. 

Pelos os próximos trés meses, Chris e eu passamos horas planejando e codifi- 
cando o GitHub. Eu continuei com o Grit e desenhei a interface do usuário. Chris 
construiu a app Rails. Nós nos encontrávamos todos os sábados para tomar deci- 
sóes de design e tentar pensar no nosso plano de pregos. Eu me lembro de um dia 
muito chuvoso em que conversamos por umas boas duas horas sobre as diferentes 
estratégias de pregos dos melhores egg rolls vietnamitas da cidade. Fizemos tudo 
isso mantendo nossos compromissos. Eu, por exemplo, trabalhava em tempo inte- 
gral na Powerset como desenvolvedor de ferramentas para o Ranking e a equipe da 
Relevance. 

Em meados de janeiro, após trés meses de noites e finais de semana, langamos 
um beta privado e enviamos convites para nossos amigos. Em meados de fevereiro, 
PJ Hyett se juntou a nós. Langamos o site ao público em 10 de abril. Náo convidamos 
o TechCrunch. Neste ponto, nós éramos apenas trés caras de 20 e poucos anos sem 
um centavo sequer de investimento externo. 

Eu ainda estava trabalhando em tempo integral na Powerset em 1 de julho de 
2008, quando soubemos que ela tinha acabado de ser adquirida pela Microsoft por 
cerca de US$ 100 milhöes. Um timing interessante. Com a aquisigäo, eu estava a ca- 
minho de ser confrontado com uma escolha muito mais cedo do que eu imaginava. 
Eu poderia me tornar um funcionário da Microsoft ou sair e ir cuidar do GitHub 
em tempo integral. Aos 29 anos de idade, eu era o mais velho dos trés GitHubbers 
e tinha acumulado uma quantidade proporcionalmente maior de dividas e despesas 
mensais. Eu estava acostumado com meu estilo de vida de seis dígitos. Para confun- 
dir ainda mais, minha esposa, Theresa, estava para voltar do seu PhD, na Costa Rica. 
Logo eu iria voltar a ser um homem casado. 

Para tornar a decisáo ainda mais difícil, a oferta de emprego da Microsoft foi ten- 
tadora. Salário, mais 300000 dólares em trés anos. Isso é dinheiro o suficiente para 
fazer qualquer pessoa pensar duas vezes sobre qualquer coisa. Entáo, fui confron- 
tado com isso: um trabalho seguro na Microsoft e com muito dinheiro garantido ou 
um trabalho arriscado, com quantidades desconhecidas de dinheiro, como empresá- 
rio. Eu sabia que as coisas com os outros Githubbers ficariam tensas se eu náo saísse 
da Powerset. Por terem guardado algum dinheiro e se tornado freelancers há algum 
tempo, ambos tinham começado a se dedicar em tempo integral no GitHub. Era 
hora de “fazer ou morrer”. Era escolher o GitHub e investir nele ou fazer a escolha 
segura e desistir do GitHub para fazer dinheiro na Microsoft. 
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Se vocé quer uma receita para uma péssima noite de sono, eu posso lhe dar. Adi- 
cione uma pedaço de “O que minha mulher acha?”, com 3.000 pedaços de Benjamin 
Franklin, misture com uma “cerveja a hora que vocé bem entender” e adicione uma 
cobertura de chance de independéncia financeira. 

Eu me tornei muito bom em chegar nos meus chefes e dar a má notícia de que eu 
estava deixando a empresa para ir fazer alguma coisa mais legal. Eu dei a notícia para 
meu chefe na Powerset na data limite de responder á proposta. Eu disse que estava 
saindo para ir trabalhar em tempo integral no GitHub. Como qualquer grande chefe, 
ele estava chateado, mas entendeu. Ele náo tentou me seduzir com um bónus maior 
ou qualquer coisa do tipo. Acho que no fundo ele sabia que eu ia sair. Talvez eu tenha 
até recebido mais incentivo para ficar do que os outros, por conta do risco. E vou Ihe 
dizer, aqueles gerentes da Microsoft eram persistentes. Eles tém bónus de retengáo 
como uma ciéncia — bem, exceto quando vocé tem um empreendedor no conjunto, 
a singularidade do mundo dos negócios. Tudo € desequilibrado quando vocé tem 
um deles por perto. 

No final, assim como Indiana Jones nunca poderia recusar a oportunidade para 
procurar o Santo Graal, eu também náo poderia perder a chance de trabalhar para 
mim mesmo em algo que eu realmente amo, não importa o quão segura outra opção 
fosse. Quando eu estiver velho e morrendo, eu pretendo olhar para trás em minha 
vida e dizer: “Uau, que aventura”, näo “Uau, me senti seguro.” 

Tom Preston-Werner é co-fundador do GitHub. 


Faca algo 


1) Quais são seus maiores medos com relação à sua carreira? Pense sobre as últimas 
decisões de carreira que você tomou. Não precisam ser grandes decisões (afinal, 
se você está fazendo escolhas influenciadas por medo, suas decisões provavel- 
mente não serão grandes). Por exemplo, pode ser se você aceitou alguma tarefa 
especial, ou se candidatou para uma promoção. Faça uma lista dessas escolhas, 
e para cada uma, obrigue-se a fazer uma avaliação honesta: o quanto dessa sua 
decisão foi conduzida pelo medo? O que você teria feito se o medo não o tivesse 
influenciado? Se a decisão foi de fato influenciada pela medo, como você pode 
revertê-la ou encontrar uma oportunidade similar, em que possa tomar a decisão 


com menos medo? 
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CAPÍTULO 7 


Seja generalista 


Por pelo menos algumas décadas, gerentes e donos de empresas desesperados tém 
fingido que o desenvolvimento de software é um processo fabril. Especificações de 
requisitos sáo criadas e os arquitetos as transformam em algo de nivel técnico. De- 
signers completam a arquitetura com a documentagäo detalhada do projeto, que é 
entregue para programadores robó, que com uma máo seguram um livro ruim e com 
a outra escrevem código. Por fim, um investigador recebe o código completo, que 
náo ganha o selo de aprovagäo a menos que cumpra as especificacóes originais. 

Náo é nenhuma surpresa que os gestores queiram que o desenvolvimento de 
software seja como uma fábrica. Eles “entendem” como fazer fábricas funcionarem. 
Temos décadas de experiéncia em como construir objetos físicos eficientemente. As- 
sim, aplicando o que aprendemos de manufatura, devemos ser capazes de otimizar o 
processo de desenvolvimento de software para como qualquer outra indústria fun- 
ciona. 

Na táo falada fábrica de software, os funcionários sáo especialistas. Eles se sen- 
tam em seu lugar na linha de montagem, combinando componentes Java ou apa- 
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rando arestas de um aplicativo Visual Basic. O investigador é um testador. Os com- 
ponentes váo passando e sáo testados e carimbados da mesma forma todo dia. De- 
signers J2EE desenham aplicações J2EE. Programadores C++ programam em C++. 
O mundo é muito limpo e organizado. 

Infelizmente, a analogia da fábrica náo funciona. Software é no mínimo táo ma- 
leável como os requisitos de software. As coisas mudam no negócio, e os empresários 
sabem que o software é soft e pode ser alterado para atender a essas mudangas. Isso 
significa que arquitetura, design, código e os testes devem todos ser criados e revisa- 
dos de uma forma mais ágil do que os processos de fabricação mais enxutos podem 
proporcionar. 

Neste tipo de ambiente de mudangas rápidas, o flexivel irá sobressair. Quando há 
pressáo, um empresário inteligente vai até um profissional de software que consiga 
resolver o problema. Entáo, como vocé se torna a pessoa cujo nome é lembrado 
quando eles estáo á procura de um super-herói para salvar o dia? A chave é ser 
capaz de resolver os problemas que possam surgir. 

Quais sáo esses problemas? É isso mesmo: vocé náo sabe. Nem eu. O que eu 
sei é que há problemas dos mais diversos, como de implantacáo, falhas de projeto 
críticos que precisam ser resolvidos e rapidamente reimplementados, integragäo de 
sistemas heterogéneos e geracáo de relatórios. Diante de um conjunto de problemas 
táo diversos como este, aquele investigador ficaria rapidamente para trás. 

O rótulo de “conhece um pouco de tudo, mas tudo de nada” é normalmente pe- 
jorativo, o que implica que o rotulado náo tem o foco para realmente mergulhar em 
um assunto e dominá-lo. Mas, quando sua loja online está fora do ar e vocé está 
perdendo centenas de vendas conforme o tempo passa, é o “conhece um pouco de 
tudo” que náo só sabe como funciona o código do aplicativo, mas também pode fazer 
debug dos processos no servidor web rodando em UNIX, analisar a configuracáo do 
seu banco de dados para possíveis gargalos de performance, e verificar a configura- 
cáo de seu roteador de rede para encontrar problemas difíceis. E, mais importante, 
depois de encontrar o problema, o “conhece um pouco de tudo” pode rapidamente 
tomar decisões de arquitetura e de design, implementar correções de código, e im- 
plantar uma correção para o sistema em produção. Neste cenário, a ideia de fábrica 
parece bem antiquada na melhor das hipóteses e terrivelmente falha na pior. 

Outro ponto em que a fábrica de software não funciona é que, em contraste com 
uma linha de montagem em que o trabalho continua vindo em um fluxo constante, 
projetos de software são geralmente cíclicos. Não só o fluxo dos projetos são cíclicos, 
mas o trabalho dentro de um projeto também é. Um programador fica lá sentado na 
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cadeira enquanto os requisitos estáo sendo especificados, arquitetados e projetados, 
ou o programador trabalha ao mesmo tempo em värios projetos. O problema com 
os programadores multitarefa € que, apesar das intengöes da fábrica de software, 
quando o bicho pega, os programadores se baseiam bastante no contexto e na expe- 
riéncia para concluir seus trabalhos. Requisitos, arquitetura e documentos de design 
podem ser um começo, mas no final, se os programadores não entenderem o que o 
sistema deve fazer, eles náo seráo capazes de implementá-lo bem. 

Claro que aqui eu náo estou pegando no pé só de programadores. O mesmo 
é verdade em quase todas os pontos da linha de montagem de software. Contexto 
importa, e ser multitarefa náo funciona. Como resultado, temos um sistema de pro- 
dução ineficiente. Já houve várias tentativas de resolver este problema de ineficiência, 
sem sair do sistema de produção de inspiração em fábricas, mas ainda não descobri- 
mos como otimizar nossas fábricas de software a um nível aceitável. 

Se você é “apenas” um programador, ou um testador, ou um designer, ou um 
arquiteto, você vai se encontrar ocioso ou fazendo trabalho pesado e sem importân- 
cia durante vários momentos do seu projeto. Se você é “apenas” um programador 
J2EE, ou um programador .NET, ou um programador de sistemas UNIX, você não 
vai ter muito a contribuir quando o foco de um projeto ou de uma empresa de mu- 
dar, mesmo que temporariamente, da sua área de foco. Não é sobre onde você está 
na cadeia de valor de trabalho percebido do projeto (onde o arquiteto tem o posto 
mais alto da realeza). É sobre o quão útil você é. 

Se seu objetivo é ser a última pessoa de pé em meio a rodadas de demissões ou 
terceirização de trabalho, é melhor se tornar “genericamente” útil. Se você tem medo 
de que o seu escritório de desenvolvimento, que antes era lotado, vire a casa de um 
bando de gente estranha, ajudaria se você percebesse que quando o time tem ape- 
nas algumas vagas, o “só testador” ou o “apenas codificador” não serão requisitados. 
Melhor, se você só quer se destacar e ser notável, envolver-se no todo é o melhor que 
você faz. 


Generalistas são raros...e por isso, preciosos. 


O caminho para se tornar um generalista é não se rotular com um papel especí- 
fico ou tecnologia. Podemos nos tornar flexíveis em nossas carreiras de muitas ma- 
neiras. Para entender o que significa ser um generalista, podemos dar uma olhada 
em como está o cenário das carreiras de TI, em diferentes aspectos independentes. 
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Eu consigo pensar em cinco, mas é claro que há uma infinidade (tudo depende de 
como vocé separa os assuntos): 


e Degrau na escada da carreira; 


Plataforma / OS; 


Código x dados; 
e Sistemas x aplicações; 


e Negócio x TI. 


Essas são diferentes formas pelas quais você poderia abordar o problema de se 
tornar um generalista. Esta é apenas uma maneira de pensar sobre toda a sua car- 
reira, e você provavelmente pode ter uma lista melhor para si próprio. Por agora, 
vamos discutir esses pontos. 

Primeiro, você pode optar por ser um líder ou gerente, ou ser uma pessoa téc- 
nica. Ou, você pode se autoclassificar um arquiteto em vez de ser um programador 
ou testador. A capacidade de ser flexível nos papéis que você pode e vai ter é um 
atributo cujo valor muitas pessoas não compreendem. Por exemplo, enquanto um 
líder forte deve evitar ao máximo se intrometer, esse novo mundo de equipes de 
desenvolvedores terceirizados pode se beneficiar de uma pessoa que sabe como li- 
derar pessoas e projetos, mas também pode arregaçar as mangas e corrigir alguns 
bugs críticos de última hora, enquanto a equipe offshore está dormindo. O mesmo 
vale para um arquiteto de software que possa acelerar dramaticamente o progresso 
em um projeto se ele escrever um pouco de código. Quando se trata de atravessar 
hierarquias, não é a relutância que impede as pessoas de fazê-lo. É a capacidade. 
Programadores nerds não podem liderar, e os líderes e gerentes não podem escrever 
código. É raro encontrar alguém seja bom nos dois. 


Suas habilidades transcendem tecnologias. 


Outra falha imperdoável é encontrada quando falamos de plataformas e sistemas 
operacionais. Ser um cara UNIX que se recusa a trabalhar com Windows é cada vez 
mais inviável. O mesmo vale para .NET vs J2EE ou quaisquer outras plataformas de 
infraestrutura. O tempo vai exigir que você seja neutro com relação à plataforma 
no seu ambiente de trabalho. Todos nós temos nossas preferências, mas você vai 
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ter que deixar seus ideais em casa. Domine um e fique bom no outro. Suas habili- 
dades devem transcender a tecnologia e plataforma. Ela é apenas uma ferramenta. 
Se queremos alguém que só saiba Windows, podemos contratá-lo nas Filipinas. Se 
quisermos alguém que realmente entenda de Windows e UNIX e pode integrá-los, 
provavelmente vamos procurar aqui por perto. Náo seja deixado de lado por causa 
de algo que é essencialmente espírito de equipe. 

A linha que divide o administrador de banco de dados (um papel solidificado 
em TI na última década) e desenvolvedor de software também é ténue. Ser um ad- 
ministrador de banco de dados ou DBA, significa em muitos lugares saber como 
usar alguma ferramenta visual de administração e como configurar um banco de 
dados. Você não precisa necessariamente saber muito sobre como usar o banco nas 
aplicações. Por outro lado, os desenvolvedores estão cada vez mais preguiçosos e 
ignorantes sobre como trabalhar com bancos de dados. Cada lado alimenta o outro. 

O que mais me surpreendeu quando eu entrei na área de TI era que muitos pro- 
gramadores (talvez a maioria) não sabiam como configurar os ambientes que eles 
utilizavam para o desenvolvimento e para deploy. Eu trabalhei com desenvolvedores 
que não conseguiam sequer instalar um sistema operacional em um computador se 
você pedisse, muito menos configurar um servidor de aplicações para fazer o deploy 
das suas aplicações. É raro encontrar um desenvolvedor que realmente entende a 
plataforma em que está trabalhando. As aplicações são melhores por consequência, 
o trabalho costuma ser feito mais rápido. 

Finalmente, como discutimos no capítulo 3, a barreira entre o negócio e TI deve 
ser derrubada já! Comece a entender como sua empresa funciona. 


Faça algo 


1) Em um pedaço de papel ou em uma lousa, liste as dimensões em que você pode 
ou não estar generalizando seus conhecimentos e habilidades. Para cada dimen- 
são, escreva sua especialidade. Por exemplo, se “sistema operacional? é uma de 
suas dimensões, você pode escrever Windows/.NET ao lado. Agora, à direita da 
sua especialidade, escreva um ou mais tópicos que você deveria aprender. Conti- 
nuando com o mesmo exemplo, você pode escrever Linux/Java (ou mesmo Ruby 
ou Perl). 


Assim que possível (mas ainda essa semana), pegue 30 minutos de seu tempo e 
comece a aprender alguma tecnologia que você listou. Não basta ler sobre ela. Se 
possível, faça um hands-on. Se é uma tecnologia web, então faça você mesmo a 
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instalacáo e configuracáo do servidor. Se é um assunto relacionado a negócios, 
escolha um de seus clientes no trabalho e chame-os para almogar ou conversar. 


CAPÍTULO 8 


Seja especialista 


“Como vocé escreveria um programa, em Java puro, que trave a Java Virtual Ma- 
chine?” Siléncio mortal. “Oi?” 

“Desculpa. Náo entendi. Vocé pode repetir a pergunta, por favor?” A voz soava 
desesperada. Eu sabia que repetir a pergunta náo iria ajudar em nada. Entáo, eu 
repeti a pergunta, devagar e em um tom de voz mais alto. “Como vocé escreveria 
um programa, em Java puro, que faça Java Virtual Machine parar de funcionar?” 

“Uh... desculpe. Eu nunca fiz isso” 

“Eu sei que não. Que tal essa pergunta: como é que você escreveria um programa 
que NÃO trave a JVM"? 

Eu estava procurando por programadores Java realmente bons. Para começar 
a entrevista, perguntei para esta pessoa (e todos os outros candidatos que eu havia 
entrevistado naquela semana) para avaliar a si mesmo em uma escala de um a dez. 
Ele disse nove. Estou esperando uma estrela aqui. Se esse cara se avalia de forma tão 
alta, por que ele não consegue pensar em algum simples truque que trave a JVM? 


A falta de profundidade técnica. 
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Muitos acreditam que ser especialista em algo significa que vocé náo sabe outras 
coisas. 


Essa pessoa se dizia especialista em Java. Se vocé o conhecesse em uma festa 
e perguntasse o que ele fazia para viver, ele diria: “Eu sou um desenvolvedor Java’. 
Ainda assim, ele nao conseguia responder a esta simples pergunta. Ele nao conseguia 
sequer chegar a uma resposta errada. Depois de intensas duas semanas e meia de 
entrevistas em uma viagem de recrutamento, esta foi a regra, não a exceção. Milhares 
de especialistas Java tinham se candidatado para as vagas abertas, mas quase nenhum 
deles sabia explicar como Classloader Java trabalhava ou então dar uma visão geral 
de como o gerenciamento de memória funciona em uma JVM. 

Claro, você não tem que saber essas coisas para escrever código sob a supervisão 
de outros. Mas estas pessoas deveriam ser especialistas. 

Muitos acreditam que ser especialista em algo significa que você não sabe outras 
coisas. Eu poderia, por exemplo, chamar minha mãe de especialista em Windows, 
porque ela nunca usou o Linux ou Mac OS X. Ou, eu poderia dizer que meus paren- 
tes na zona rural do Arkansas são especialistas em música country, porque nunca 
ouviram nada diferente. 

Imagine que você visite o seu médico da família, reclamando de um nódulo es- 
tranho no seu braço direito. O seu médico indica um especialista para fazer uma 
biópsia. E se esse especialista fosse uma pessoa cujas únicas credenciais como espe- 
cialista eram que ele não compareceu às aulas na escola de medicina ou nunca teve 
experiência em residências que não eram diretamente ligadas ao procedimento es- 
pecífico que ele vai realizar hoje em você? Eu não quero dizer que eles foram mais 
fundo nos temas relacionados ao procedimento de hoje. E se ele tivesse apenas visto 
por cima essas assuntos e não soubesse de mais nada? “E se essa máquina ali começar 
a apitar durante o procedimento?”, você pode perguntar. “Ah, isso nunca aconteceu 
antes. Não vai acontecer desta vez. Eu não sei o que a máquina faz, mas ela nunca 
apita” 

Felizmente, a maioria dos desenvolvedores de software não é responsável por si- 
tuações de vida ou morte. Se eles fracassarem, isso geralmente vai resultar em atrasos 
nos projetos ou bugs que simplesmente custarão dinheiro de seus empregadores, não 
vidas. 

Infelizmente, a indústria de software tem movimentado um monte desses espe- 
cialistas rasos, que usam o termo especialista como uma desculpa para saber só uma 
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coisa. Na indústria médica, um especialista é alguém com profundo conhecimento 
de alguma área específica. Doutores encaminham os pacientes para especialistas, 
porque, em certas circunstáncias, o especialista pode cuidar melhor do paciente do 
que um clínico geral. 

Entáo, o que um especialista de software deve ser? Eu posso Ihe dizer o que eu 
estava procurando por toda a parte durante a viagem de recrutamento. Era por pes- 
soas que entendessem profundamente programacáo Java e ambiente de implantagäo. 
Eu queria pessoas que pudessem dizer “estive lá, fiz isso” em 80% das situagöes e cuja 
profundidade de conhecimento passasse tranquilidade para as outras 20% das situa- 
ções. Eu queria alguém que, ao lidar com abstrações de alto nível, entendesse os de- 
talhes da implementagäo dessas abstragöes. Eu queria alguém que pudesse resolver 
qualquer problema de implantacáo que encontrássemos ou que ao menos soubesse 
a quem pedir ajuda se necessário. 

Este é o tipo de especialista que vai sobreviver na indústria de TI. Se vocé é um 
especialista em .NET, isso nao é uma desculpa para nao saber nada, além de .NET. 
Isso significa que, se tem a ver com .NET, vocé é o cara. Servidores IIS travados e 
precisando de reboot? “Não tem problema” Integração de código fonte com o Visual 
Studio .NET? “Eu lhe mostro como.’ Clientes à beira de um ataque de nervos por 
conta de problemas de performance que ninguém sabe o que é? “Dé 30 minutos.” 

Se isso náo é o que ser um especialista significa para vocé, entáo eu espero que 
náo saia falando que é um. 


Faca algo 


e Você usa uma linguagem de programação que compila e roda numa máquina 

virtual? Se assim for, levará algum tempo para aprender sobre os detalhes 
de como a VM trabalha. Considerando Java, .NET e Smalltalk, muitos livros 
e sites são dedicados ao tema. É mais fácil aprender sobre elas do que você 
imagina. 
Independente de a sua linguagem se basear em uma VM, leva algum tempo 
para estudar o que acontece quando você compila um arquivo fonte. Como é 
que o código que você digitou passa de texto legível para as instruções que um 
computador pode executar? O que significaria escrever o seu próprio compi- 
lador? 


Quando você importa ou usa bibliotecas externas, de onde elas vêm? O que 
realmente significa importar uma biblioteca externa? Como é que o seu com- 
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pilador, sistema operacional, ou máquina virtual liga vários pedagos de código 
para formar um sistema coerente? Aprender esses pontos fará com que vocé 
fique muitos passos mais próximos de ser um especialista na sua tecnologia 
preferida. 


Encontre uma oportunidade — no trabalho ou fora dele — de dar uma aula 
sobre algum aspecto de uma tecnologia em que vocé gostaria de se aprofun- 
dar. Como vocé verá em “Seja um mentor”, capítulo 14, o ensino é uma das 
melhores maneiras de aprender. 


CAPÍTULO 9 


Não coloque todos os seus ovos 
num só cesto 


Uma vez, enquanto gerenciava um time de desenvolvedores, eu perguntei a um dos 
meus funcionários: “O que vocé quer fazer com sua carreira? O que vocé quer ser?” 
Fiquei muito decepcionado com sua resposta: “Quero ser um arquiteto J2EE” Eu 
perguntei: “Por que náo um designer Microsoft Word ou um instalador RealPlayer?” 

Ele queria fazer sua carreira em torno de uma tecnologia específica, criada por 
uma empresa específica, da qual ele náo era um empregado. E se a empresa acabar? 
E se sua tecnologia se tornar obsoleta? Por que vocé quer confiar sua carreira a uma 
empresa de tecnologia? 

De alguma maneira, como uma indústria, nós mesmos nos enganamos ao pen- 
sar que líder de mercado é a mesma coisa que padráo. Assim, para algumas pessoas, 
parece inteligente fazer com que o produto de uma empresa faga parte da sua iden- 
tidade. Pior ainda, alguns baseiam suas carreiras em torno de produtos que nem 
líderes de mercado sáo — pelo menos até suas carreiras falharem miseravelmente e 
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sua única escolha for repensar sua estratégia perdedora. 

Vamos parar para lembrar que devemos pensar na nossa carreira como um ne- 
gócio. Embora seja possível construir um negócio que seja um parasita de outro 
negócio (como empresas que constroem softwares de remogáo de spyware para su- 
prir falhas de seguranga do navegador da Microsoft), como uma pessoa, isso é uma 
coisa extremamente arriscada de se fazer. Uma empresa, como a do exemplo do 
spyware, geralmente pode reagir 4s mudangas no mercado, como uma melhoria na 
seguranga do navegador da Microsoft (ou a Microsoft decidir entrar no mercado de 
remoção de spyware), enquanto que uma pessoa não tem a mão de obra ou dinheiro 
sobrando, para de repente, mudar de direção na carreira. 


Uma visão centrada apenas no fornecedor é uma visão míope. 


O lado triste da visão centrada no fornecedor é que, normalmente, os detalhes de 
implementação do software de um fornecedor são um segredo. Você pode aprender 
bastante sobre o software de alguém, até chegar na barreira do serviço profissional. 
Essa é uma barreira artificial que a empresa impõe entre você e a solução para um 
problema possível, dessa forma, ela pode lucrar vendendo o suporte. Algumas vezes, 
essa barreira é proposital, e às vezes é um efeito colateral da tentativa da empresa de 
proteger sua propriedade intelectual (não compartilhando o código-fonte). 

Assim, apesar de que o investimento em uma única determinada tecnologia seja 
quase sempre uma má ideia, se você precisar fazer isso, considere focar em uma 
opção open source, ao invés de uma comercial. Mesmo que você não possa ou não 
queira usar uma solução open source no seu trabalho, use-a para conseguir ir mais 
a fundo na tecnologia. Por exemplo, você pode querer se tornar um especialista em 
como funcionam os servidores de aplicação J2EE. Em vez de concentrar seus esforços 
sobre os detalhes de como configurar e implantar um servidor de aplicação comercial 
(afinal, qualquer um pode descobrir como ajustar as configurações em um arquivo 
de configuração, certo?), baixe o código fonte do JBoss ou Geronimo e reserve um 
tempo para si mesmo, não só para aprender a operar os servidores, mas para estudar 
suas partes internas. 

Em pouco tempo, você vai perceber que naturalmente o seu ponto de vista vai 
mudar. Esse negócio de J2EE (ou seja lá o que você escolheu estudar) realmente não 
é nada de tão especial. Agora que você vê os detalhes da implementação, pode per- 
ceber que há padrões conceituais ali no meio. E começar a perceber que, seja com 
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Java ou outra linguagem ou plataforma, arquitetura distribuida é arquitetura distri- 
buida. Sua visão aumenta e sua mente começa a abrir. Você começa a perceber que 
os conceitos e padróes que o seu cérebro está organizando e assimilando sáo muito 
mais escaláveis e universais do que qualquer tecnologia de uma empresa específica. 
“Náo importa o fornecedor, eu sei como criar um sistema!” 


Faca algo 


1) Tente um projeto pequeno, duas vezes. Tente uma vez em sua tecnologia padráo e, 
depois, da forma mais idiomática possível, faça em uma tecnologia concorrente. 
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CAPÍTULO 10 


Ame-o ou deixe-o 


Pode soar como uma espécie de historinha cliché feita pra despertar aquela exaltacáo 
idealista em vocé, mas é muito importante para deixar de falar. Se vocé quer ser 
realmente bom no seu trabalho, vocé tem que ser apaixonado por ele. Se vocé nao 
da a minima pra ele, isso vai transparecer. 

Quando minha esposa e eu nos mudamos para Bangalore, eu estava bem ani- 
mado. Pela primeira vez na minha carreira, estava ansioso para encontrar tecnó- 
logos com paixáo por aprender. Estava esperando uma vida pós-trabalho cheia de 
reuniões de grupo de usuários e profundas discussões filosóficas sobre técnicas e me- 
todologias de desenvolvimento de software. Eu estava esperando encontrar o Silicon 
Valley da Índia cheio de artesáos, entusiastas da grande arte de desenvolver software. 

O que eu encontrei foi um monte de gente que estava lá só pra receber seu salário 
e poucos artistas apaixonados. 

Era igual ao lugar de onde vim. 

Claro, na hora eu náo percebi que era igual ao lugar de onde vim. Eu tinha algu- 
mas referéncias dos Estados Unidos, mas sempre achei que era porque eu trabalhava 
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em cidades ruins ou em empresas com ambiente ruim. Sempre achei que minhas 
primeiras experiências na área de TI tinham sido exceções. “Deve ser assim com 
a maioria dos desenvolvedores”, pensava. “Eu só náo encontrei o ambiente certo 
ainda” 

Comecei a trabalhar no departamento de TI da minha universidade através de 
uma recomendação do meu amigo Walter, que tinha me visto trabalhar com com- 
putadores, o suficiente para saber que eu provavelmente poderia fazé-los trabalhar 
melhor do que a maioria das pessoas que precisavam de ajuda na universidade. Eu 
náo acreditava que eu podia, sem ter nenhum tipo de treinamento. Eu era apenas um 
tocador de saxofone que gostava de jogar videogame. Mas Walter me candidatou em 
uma vaga e marcou uma entrevista para mim. Fui contratado sem nem uma única 
questáo técnica ter sido perguntada, e era para comecar imediatamente. 

Quando eu apareci no trabalho, estava morrendo de medo de ser descoberto 
como um charlatáo, o que eu realmente era. “O que é que este saxofonista está fa- 
zendo aqui com a gente, profissionais treinados?” Afinal, eu estava trabalhando com 
gente que tinha níveis avançados em ciência da computação. E aqui estava, tendo 
cursado só uma parte da faculdade de Música, tentando me encaixar como se eu 
soubesse alguma coisa. 

Depois de alguns dias de trabalho, a verdade começou a afundar. “Essas pes- 
soas não fazem ideia do que estão fazendo!” Na verdade, algumas pessoas estavam 
me observando trabalhar e tomando notas! Pessoas com mestrado em ciência da 
computação! 

Minha primeira reação foi assumir que eu estava cercado por idiotas. Afinal, eu 
não tinha nenhum treinamento formal. Passei minhas noites tocando em bandas 
de bar e meus dias jogando videogame. Eu tinha aprendido a trabalhar com com- 
putadores só porque eu estava interessado neles. Na verdade, eu aprendi a escrever 
programas porque eu queria fazer meus próprios jogos de computador. Eu chegava 
em casa tarde depois de uma noite ensurdecedora em algum bar e ficava até o solnas- 
cer em sites Gopher com tutoriais sobre programação. Aí eu ia dormir, acordava e 
continuava estudando até que a hora em que eu tinha que sair e tocar novamente. Eu 
parava meus estudos com meus amados jogos, comia e depois voltava para brincar 
com Gopher e qualquer compilador que eu conseguisse fazer funcionar. 


Trabalhe porque vocé náo poderia náo trabalhar. 


Pensando bem, eu era viciado, mas de um jeito bom. Meu desejo por criar tinha 
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sido despertado em grande parte da mesma forma que quando comecei a escrever 
música clássica ou tocar jazz. Eu era obcecado por aprender tudo o que eu pudesse. 
Eu náo estava ali para uma nova carreira. Na verdade, muitos dos meus amigos 
músicos achavam isso uma irresponsável distracáo da minha carreira atual. Eu estava 
lá porque eu náo poderia náo estar. 

Esta foi a diferenga entre eu e os meus superestudados, mas de baixo rendimento, 
colegas de trabalho. Paixáo. 

Essas pessoas náo tinham ideia de por que eles estavam na área de TI. Eles se 
encontraram por acaso em suas carreiras, porque acharam que programar podia pa- 
gar bem, porque os seus pais os incentivaram ou porque náo conseguiam pensar em 
um curso melhor na faculdade. Infelizmente o seu desempenho no trabalho refletia 
isso. 

Se vocé pensar nas biografias que vocé leu ou nos documentarios a que assistiu 
sobre os grandes nomes em varios campos, esse mesmo padrao de vicio e comporta- 
mento apaixonado aparece. Diz-se que o grande saxofonista de jazz, John Coltrane, 
praticava tanto que seus lábios chegavam a sangrar. 

É claro, o talento natural tem um grande papel na habilidade. Nem todos podem 
ser Mozart ou Coltrane. Mas todos nós podemos dar um grande passo longe da 
mediocridade encontrando um trabalho pelo qual somos apaixonados. 

Pode ser um domínio ou negócio que lhe interesse. Ou, por outro lado, pode 
ser uma tecnologia específica ou domínio de negócio que o afunde. Ou um tipo de 
empresa. Talvez você esteja destinado a pequenas equipes ou a times grandes. Ou a 
processos rígidos. Ou a processos ágeis. Qualquer que seja a combinação, leva algum 
tempo para encontrar a sua. 

Você pode fingir por um tempo, mas a falta de paixão vai pegar você e seu tra- 
balho. 


Sendo um oportunista em série 


por James Duncan Davidson 

Desde o início, eu não tive o que muitos consideram uma carreira tradicional. 
Pelo contrário, tem sido muito mais um caminho de seguir as oportunidades con- 
forme elas aparecem. A primeira apareceu enquanto eu estava na escola trabalhando 
em uma licenciatura em arquitetura. Eu tinha decidido na idade de 15 ou 16 anos que 
eu queria ser um arquiteto, e passei muito tempo investindo no futuro. Mas as se- 
mentes do que realmente seria a minha carreira depois da escola foram plantadas 
em meu fascínio precoce com sistemas online BBS. Eu era um daqueles garotos que 
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amavam o modem de 300 no PC da família. Isso me levou, eventualmente, para a 
internet, que por sua vez me levou a Gopher e, entáo, World Wide Web. 

A web imediatamente me fisgou. Eu construí vários sites pessoais em rápida 
sequéncia e aproveitei toda a tecnologia a minha disposigáo, ensinando a mim 
mesmo conforme necessário. Na época, eu pensei neste trabalho como experimen- 
tos em cyber-architetura. Parece muito grandioso e até mesmo bastante idiota agora, 
mas era o mundo em que nós dos primeiros tempos da web vivíamos. Estávamos 
tentando imaginar o que o futuro poderia trazer. 

Naturalmente, o verdadeiro trabalho de construir o futuro da internet náo estava 
acontecendo nos laboratórios de arquitetura. Ele estava acontecendo no mundo dos 
negócios. Em pouco tempo, e com base no que eu tinha feito com o meu site pú- 
blico, fui contatado por uma startup que estava construindo websites para os Hil- 
ton, Better Business Bureau e semelhantes. Eles tinham visto os sites eu havia cons- 
truído, e, aparentemente, eu tinha o conjunto de habilidades de que eles precisavam. 
Ofereceram-me um trabalho com o que parecia, na época, um salário ridiculamente 
grande. Aceitei-o, imaginando que eu poderia aproveitar a onda por um tempo, ga- 
nhar algum dinheiro, e voltar para a escola em poucos anos. 

Foi em 1995. Mal sabia eu quáo longe as coisas iriam e aonde um pouco de von- 
tade de mergulhar em algo novo iria me levar. 

Enquanto eu ajudava a construir a primeira versäo do website Hilton, que tinha 
posicionamento de reservas em tempo real, aprendi como construir sites usando 
uma variedades de tecnologias do lado do servidor. Em poucos meses, eu passei de 
aprendiz a criador de meus próprios frameworks. Olhando para trás, parece ridículo, 
mas naquele momento, isso era o que era necessário. Eu vi uma abertura, aceitei-a, 
e apostei nela por tudo que valia, reinventando a mim mesmo conforme necessário. 

Uma coisa levou à outra. Em 1997, fui para a JavaSoft trabalhar aplicações servi- 
doras, e em poucos anos, acabei encarregado da especificagäo Servlet. Infelizmente, 
era um esforgo subfinanciado, e eu náo tinha uma equipe para me ajudar a fazer tudo 
que precisava ser feito, incluindo construir uma nova implementacáo de referéncia. 
Mas eu náo deixei isso me parar, e dei início ao desenvolvimento de uma implemen- 
tacáo completamente nova, que eventualmente foi langada como o Kit JavaServer 
Web Development. Poucos se lembram desse software. Mas a maioria dos que tra- 
balham com Java sabe sobre a versáo seguinte daquele código. É o chamado Tomcat. 
E ele foi lançado mundialmente via Fundação Apache com um sócio chamado Ant. 
A história por trás desse lançamento daria um livro. O suficiente é dizer que tudo 
aconteceu graças a um perfeito conjunto de oportunidades nas quais estive disposto 
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a apostar. 

Depois de trabalhar na Sun por quatro anos e encarar uma questáo do tipo “O 
que eu devo fazer agora?”, decidi me tornar independente. Escrevi livros para a 
O'Reilly, desenvolvi software para Mac, desenvolvi alguns softwares próprios que 
acabei nao lancando. E terminei fazendo um pouco de desenvolvimento Ruby on 
Rails. Ser um desenvolvedor de software independente foi bom para mim e sou bas- 
tante bom nisso. Mas ao longo do caminho, um hobby que eu estava perseguindo 
começou a se transformar em uma própria carreira. 

Além de ser um estudante de arquitetura que se tornou tecnólogo, eu era tam- 
bém um fotógrafo havia um bom tempo. Minha avó tinha me ensinado o básico. 
Meus pais me encorajaram. Como resultado, até onde posso me lembrar, eu tinha 
uma câmera por perto. Isso tem sido uma grande parte da minha vida. Aliás, o soft- 
ware não lançado que eu escrevi para mim mesmo depois de deixar a Sun era para 
o trabalho com fotografia. 

Em 2005, dez anos depois que eu fiz uma pausa e mudei de estudante de arqui- 
tetura para desenvolvedor de software, fui chamado por meus amigos do grupo de 
conferências O'Reilly. Eles precisavam de alguém para documentar seus eventos e 
perguntaram se eu não estaria interessado em ir tirar algumas fotos. Eu aceitei, mas 
em vez de somente tirar algumas fotos, fui além da minha causa. Fiquei maluco e 
trabalhei em todas as sessões importantes, e postei imagens no Flickr para forne- 
cer um retorno extremamente rápido. Fui convidado de novo e, nos últimos quatro 
anos, construí um negócio em torno disso com uma boa gama de clientes. 

Enquanto escrevo isso, eu ainda faço código de tempos em tempos, e até de- 
senvolvo um pouco para alguns clientes. Mas, na maior parte, eu sou um fotógrafo 
full-time nos dias de hoje. Contudo, isso pode mudar. Nunca se sabe. É difícil dizer 
o que o futuro trará. 

O que eu sei é que sou um oportunista. Quando vejo algo interessante e excitante 
para mim, eu mergulho dentro disso e faço o que for preciso para obter sucesso. Ge- 
ralmente, isso significa aprender habilidades e desenvolver novas capacidades. Al- 
guns podem achar que construir novas habilidades é um entrave, mas por alguma 
razão, eu adoro aprender como fazer coisas novas. Afinal, novas habilidades per- 
mitem que você faça coisas novas. E eu nunca me defini por minhas habilidades. 
Ao contrário, sempre me defini pelo que fiz e pelo que eu quero fazer em seguida. 
Habilidades são apenas um caminho para chegar lá. 


James Duncan Davidson é um programador e fotógrafo. 
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Faca algo 


1) 
2) 
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Vá encontrar um emprego pelo qual vocé seja apaixonado. 


Começando na próxima segunda-feira, mantenha um registro simples nas pró- 
ximas duas semanas. A cada dia de trabalho, avalie seu nível de empolgação de 1 
a 10. 1 significa que você preferia estar doente do que ir ao trabalho e 10 significa 
que vocé náo consegue ficar na cama, pois está consumido pela ideia de finalizar 
a sua próxima tarefa. 


Depois de duas semanas de registro, analise os resultados. Houve picos? Houve 
tendéncias? Foi tudo baixo ou tudo alto? Qual seria a sua nota média se isso fosse 
um teste de escola? 


Para as próximas duas semanas, toda manhá planeje como vocé fará amanhá ser 
um 10. Planeje o que vocé vai fazer hoje para fazer com que amanhá seja um des- 
ses dias de trabalho que vocé mal pode esperar para comegar. Cada dia, registre 
o nível de empolgação do dia anterior. Se depois de duas semanas as coisas não 
estiverem boas, talvez seja hora de pensar em uma mudança. 


CAPÍTULO 11 


Aprenda a pescar 


Lao Tzu disse: “Dé a um homem um peixe, e alimente-o por um dia. Ensine um 
homem a pescar, e alimente-o por toda a vida”. Isso é tudo muito certo. Mas Lao Tzu 
náo menciona a situacáo em que o homem náo quer aprender a pescar e lhe pede 
outro peixe no dia seguinte. Educagäo exige tanto um professor como um estudante. 
Muitos de nós somos muitas vezes relutantes em ser um estudante. 


Nao espere que lhe digam. Pergunte! 


Mas o que é um peixe na indústria de software? É o processo de utilização de 
uma ferramenta ou alguma parte de uma tecnologia ou uma informagäo específica 
do domínio de negócio no qual vocé está trabalhando. É como baixar uma branch es- 
pecífica do sistema no controle de versáo, ou colocar no ar um servidor de aplicacöes 
para o desenvolvimento. Muitos de nós interpretam isso como definitivo. “Alguém 
pode cuidar disso para mim”, vocé pode pensar. O cara do build conhece o sistema 
de controle de versáo. Vocé só precisa pedir a ele para definir as coisas quando vocé 
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precisar. A equipe de infraestrutura sabe como os firewalls entre vocé e seus clientes 
sáo configurados, por isso, se vocé tem uma necessidade, basta enviar um e-mail e a 
equipe vai cuidar disso. 

Quem quer ficar á mercé de outra pessoa? Ou pior: se vocé estivesse contratando 
alguém para fazer um trabalho para vocé, vocé ia gostar que ele estivesse á mercé dos 
especialistas? Eu náo. Eu ia querer contratar alguém autossuficiente. 

O jeito mais óbvio para comegar é aprender as ferramentas do seu mercado. Con- 
trole de versáo, por exemplo, é uma ferramenta poderosa. Uma parte importante da 
sua função é focada em tornar os desenvolvedores mais produtivos. Não é apenas 
o lugar onde você coloca o seu código quando você o julga pronto, e você não deve 
tratá-lo como tal. É uma parte integrante do seu processo de desenvolvimento. Não 
deixe que uma coisa tão importante seja como um voodoo para você. Um desenvol- 
vedor autossuficiente pode facilmente ver as diferenças entre a versão de um projeto 
que ele pegou e a última versão estável no repositório. Ou talvez você precise baixar 
a versão do último release e fazer uma correção de um bug. Se aparece um bug crí- 
tico no meio da noite, você não vai querer chamar alguém para pedir que lhe dêem a 
versão correta do código para você resolver os problemas. Isso vale para IDEs, siste- 
mas operacionais e praticamente todas as partes de infraestrutura do seu código ou 
processo. 

Igualmente importante é a plataforma tecnológica que você está usando. Por 
exemplo, você pode estar desenvolvendo aplicações usando J2EE. Você sabe que deve 
criar várias classes, interfaces e scripts de deploy. Mas você sabe por quê? Você 
sabe como essas coisas são usadas? Quando você inicia um container J2EE, o que 
realmente acontece? Você pode não ser um desenvolvedor de servidor de aplicação, 
mas saber como eles funcionam possibilita que você desenvolva código confiável 
naquela plataforma e resolva os problemas quando algo der errado. 

Uma maneira particular e fácil de ser folgado é usar vários wizards que geram 
código para você. Isso é particularmente predominante no mundo de desenvolvi- 
mento Windows, em que, as ferramentas de desenvolvimento tornam várias tarefas 
realmente fáceis. O lado negativo é que muitos desenvolvedores Windows não têm 
ideia de como seus códigos realmente funcionam. O trabalho dos wizards continua 
sendo um mistério mágico. Não me leve a mal - geradores de código, quando usa- 
dos corretamente, podem ser uma ferramenta muito útil. Por exemplo, são eles que 
traduzem C# de alto nível para bytecodes que podem rodar em .NET. Você obvi- 
amente não gostaria de ter que escrever todos esses bytecodes você mesmo. Mas, 
especialmente em níveis mais altos, deixar os wizards fazerem seu trabalho torna o 
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seu conhecimento raso e o deixa limitado ao que as ferramentas podem fazer por 
vocé. 

Nós podemos facilmente ignorar o “peixe” em nosso domínio de negócio. Se 
está trabalhando para uma empresa de hipotecas, vocé pode pedir para um especi- 
alista o cálculo da taxa de juros para cada cenário que vocé precisar nos testes, ou 
poderia você mesmo aprender como calcular. Embora interações com seus clientes 
sejam boas, e é bom clarear os requerimentos do negócio com eles (o contrário de 
entender pela metade e preencher os detalhes vocé mesmo), imagine quáo rápido 
você poderia avançar se realmente soubesse os detalhes do dominio em que está tra- 
balhando. Vocé provavelmente náo vai saber cada regra de negócio - e nem é sua 
funcáo. Mas vocé pode, pelo menos, aprender o básico. Muitas das melhores pessoas 
que trabalham com software, com quem trabalhei durante anos, tornaram-se mais 
especialistas em seus dominios do que até alguns de seus clientes. Isso resulta em 
produtos melhores. Alguém que é ignorante em domínio vai deixar passarem erros 
bobos - erros que um conhecimento básico poderia evitar. Além disso, ele trabalha- 
ria mais lentamente (e custaria mais à empresa) do que o desenvolvedor que entende 
do negócio. 

Para nós, desenvolvedores de software, a intenção de Lao Tzu pode ser igual- 
mente interpretada como “Peça um peixe; coma por um dia. Peça a alguém para 
ensinar-lhe a pescar; coma para a vida toda”. Melhor ainda, não peça para ser ensi- 
nado - vá aprender você mesmo. 


Faça algo 


1) Como e por quê? - tanto enquanto você está sentado lendo este livro, ou na 
próxima vez em que estiver no trabalho, pense sobre as partes do seu trabalho 
que você entende por completo. Você pode se fazer duas perguntas extremamente 
úteis sobre qualquer assunto para mergulhar fundo nele: como isso funciona? E 
por que isso tem que acontecer? 


Você pode não conseguir responder as perguntas, mas o simples ato de fazê-las 
vai levar sua mente a um novo quadro e pode gerar um nível mais alto de cons- 
ciência sobre seu ambiente de trabalho. Como o servidor IIS acaba passando 
requests para minhas páginas ASP.NET? Como eu devo gerar essas interfaces e 
scripts de deploy para minhas aplicações EJB? Como meu compilador lida com 
linkagem dinâmica ou estática? Como calculamos a taxa de modo diferente se 
um comprador mora em outro estado? 
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Claro, a resposta para qualquer dessas perguntas levará a uma outra potencial 
oportunidade de se fazer a pergunta mais uma vez. Quando vocé náo puder mais 
avancar na árvore do como e do porqué, vocé provavelmente tera ido longe o 
suficiente. 


Dica - escolha uma das mais críticas, porém negligenciadas, ferramentas da sua 
caixa de ferramentas e foque nela. Talvez seja seu sistema de controle de ver- 
são, talvez uma biblioteca que você use bastante mas procurou apenas superfici- 
almente, ou talvez o editor que você usa pra programar. 


Quando você escolher a ferramenta, reserve um pequeno período de tempo todos 
os dias para aprender uma coisa nova sobre ela que vai lhe tornar mais produtivo 
ou lhe dar mais controle sobre seu ambiente de desenvolvimento. Você pode, por 
exemplo, escolher dominar o GNU Bourne Again Shell, também conhecido como 
bash. Durante um desses momentos em que sua mente começa a fugir do que 
deve ser feito, em vez de ir para o Slashdot ou Facebook, você poderia procurar na 
internet por dicas de bash. Em um minuto ou dois, você deve encontrar algo útil 
que você não sabia sobre como usar o shell. Claro, agora que tem um novo truque, 
você pode mergulhar em suas entranhas com uma série de como e porquês. 


CAPÍTULO 12 


Aprenda como os negócios 
realmente funcionam 


No capítulo anterior, nós discutimos a importáncia de fazer uma escolha intencio- 
nal sobre o domínio de negócio no qual vocé trabalha. Conhecimento de domínio, 
sendo na melhor das hipóteses um diferencial para empregos e na pior das hipóte- 
ses um estraga-prazeres, náo é algo que vocé deva subestimar. Antes de fazer um 
investimento para aprender os prós e contras de um dominio de negócios, vocé de- 
veria se certificar de que está investindo na coisa certa para vocé e para a situacáo do 
mercado. 

Mas há uma parte do conhecimento que náo é nem técnica nem de domínio es- 
pecífico e náo será ultrapassada em breve: o básico de finangas. Independentemente 
da sua linha de negócio, se é de manufaturas, assisténcia médica, sem fins lucrativos, 
ou uma instituicáo educacional, ainda se trata de negócios. E isso é por si só uma 
área de conhecimento que alguém pode - e até deve - aprender. 


Eu me lembro de quando eu era um jovem programador indo para reunióes 
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da equipe, meus olhos vidrados enquanto algum líder, com quem eu nunca tinha 
trabalhado diretamente, mostrava um monte de números que eu acreditava serem 
completamente irrelevantes para mim. Eu só quero voltar e terminar a funcionalidade 
que estou trabalhando, eu choramingava para mim mesmo. Meus colegas sentavam- 
se juntos, parecendo uma fila de criangas contorcidas numa longa viagem de carro. 
Nenhum de nós entendia o que estava sendo apresentado, e nenhum de nós seimpor- 
tava. Nós culpávamos os gerentes incompetentes que haviam convocado a reuniáo, 
pelo que sentíamos que era uma completa perda de tempo. 


Vocé náo pode criativamente ajudar em um negócio antes de saber como ele funciona. 


Olhando para trás, eu percebo como nós éramos bobos. Trabalhávamos para 
uma empresa, e nossa fungäo era contribuir para ou fazer, ou economizar dinheiro 
para aquela empresa. Ainda assim náo entendíamos o básico de como um negó- 
cio se torna lucrativo. Pior ainda, nós náo pensávamos que era nosso dever saber. 
Nós éramos programadores e administradores de sistema. Pensávamos que nossos 
trabalhos eram estritamente sobre aqueles tópicos aos quais nos devotávamos. Con- 
tudo, como nós supostamente poderíamos contribuir criativamente para que aquele 
negócio fosse rentável, se nem mesmo entendíamos como isso funcionava? 

O uso da palavra criativamente no parágrafo anterior é a chave. É plausível ter 
a visáo de que somos, de fato, especialistas em TI e que € para isso que somos pa- 
gos. Dados os projetos e liderança corretos, nós deveríamos nos esforçar em tarefas 
que contribuíssem para a empresa. Não precisamos entender totalmente como uma 
empresa opera para dar-lhe valor. 

Mas para criativamente adicionar valor, é preciso uma compreensão mais com- 
pleta do ambiente de negócios em que você trabalha. No mundo dos negócios, ou- 
vimos a frase ponto de partida o tempo todo. Quantos de nós realmente entendem 
o que é o ponto de partida e o que contribui para ele? Mais importante, quantos de 
nós realmente entendem como nós contribuímos para o ponto de partida? A or- 
ganização é um centro de custo ou de lucros (você adiciona ou retira do ponto de 
partida)? 

Conhecer a conduta financeira - e linguagem - da sua empresa vai lhe propor- 
cionar a habilidade de fazer mudanças significativas, em vez de tentar acertar no 
escuro em coisas que lhe parecem intuitivamente certas. 


52 


Casa do Código Capítulo 12. Aprenda como os negócios realmente funcionam 





Faca algo 


1) Procure um livro básico sobre negócios, e trabalhe com ele. Uma dica para en- 
contrar um bom livro com uma visáo geral é procurar por livros sobre MBA. Um 
desses livros que eu acho particularmente útil (e agradavelmente curto) é o The 
Ten-Day MBA [9]. Vocé realmente pode conclui-lo em dez dias. Ele nao custa 
caro. 


2) Peça a alguém para orientá-lo na área de finanças da sua empresa e expicar como 
funcionam as coisas (se isso for uma informagäo que sua empresa náo se importe 
em compartilhar com seus funcionários). 


3) Explique para eles de volta. 
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CAPÍTULO 13 


Encontre um mentor 


Uma coisa que a cultura musical do jazz realmente acertou foi a prática de mentoria. 
No mundo do jazz, é comum os jovens músicos procurarem os mais experientes, que 
os carregaráo sob sua asas e passaráo seus conhecimentos de jazz. Mas isso náo para 
por aí. Esses músicos mais velhos geralmente servem como um conselheiro de car- 
reira, e da vida toda. Em troca, os músicos jovens sáo devotamente fiéis, construindo 
uma rede de apoio de apreciadores fanáticos em torno de seus mentores. 

Contatos sáo feitos e músicos sáo contratados todos os dias por meio desses rela- 
cionamentos. A sociedade do jazz criou uma cultura auto-organizada e um conjunto 
de costumes em torno do relacionamento com o mentor. É um sistema que funciona 
táo bem que vocé suspeitaria que ele é guiado por algum tipo de entidade organiza- 
dora. 


É OK depender de alguém. Só tenha certeza de que é a pessoa certa. 


No mundo profissional tradicional (e especificamente na área de TI), nós esta- 
mos menos propensos a pedir ajuda uns aos outros. Depender dos outros é fre- 
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quentemente visto como um sinal de fraqueza. Temos medo de admitir que náo 
somos perfeitos. Tudo é competição. Apenas os fortes sobrevivem, e isso é tudo. In- 
felizmente, isso leva a um sistema de mentoria extremamente subdesenvolvido. Se 
tivéssemos que perguntar a um grupo de músicos de jazz: “Quem é seu mentor?” a 
maioria deles teria uma resposta. Agora faca a mesma questáo para programadores. 
Nos Estados Unidos, eles provavelmente responderiam “O qué?”. 

Nem sempre foi assim por aqui. A história do oeste inclui um próspero sistema 
de mentoria profissional, que vem desde a Idade Média. A abordagem do artesatado 
ao treinamento profissional era ainda mais forte e mais formalizado que o sistema 
que evoluiu na cena musical. Pessoas jovens comegavam suas carreiras profissionais 
como aprendizes de respeitáveis mestres artesáos. Elas trabalhavam em troca de um 
salário nominal e pelo privilégio de aprender com o mestre, cuja obrigacáo era trei- 
nar os discípulos para criarem coisas seguindo a mesma tradição (e qualidade) que 
a sua própria. 

O primeiro e mais importante propósito de um mentor é ser um modelo a seguir. 
É difícil saber o que é possível ser feito até que vocé veja alguém que possa ir além dos 
limites que você conhece. Um modelo estabelece o padrão do que “bom” significa. 
Se você se imaginasse como um jogador de xadrez, por exemplo, só o fato de poder 
vencer as pessoas de sua família imediata pode ser muito bom. Contudo, se você 
jogasse contra um competidor de campeonatos, você descobriria que o xadrez é um 
jogo muito mais denso do que você jamais pensava. Se você fosse jogar contra um 
grande mestre, você teria outra revelação. Se você continuasse jogando e derrotando 
apenas os membros de sua família, você poderia ficar com a ideia de que você é 
realmente bom no xadrez. Sem um modelo a seguir, não há incentivo para melhorar. 

Um mentor também pode dar estrutura para seu processo de aprendizagem. 
Como você viu no capítulo anterior, você tem uma enorme quantidade de escolhas 
para fazer sobre as tecnologias e domínios em que vai investir. Às vezes, muitas pos- 
sibilidades podem o travar. Com certeza, é melhor estar se movendo em uma direção 
do que ficar sentado parado. Um mentor pode ajudar a escolher no que focar suas 
energias. 

Quando eu comecei minha carreira, trabalhando com suporte, eu conheci um 
santo chamado Ken, que era um dos administradores da rede da nossa universidade. 
Ele veio me salvar de um grande problema com a rede NetWare do nosso campus, 
que estava atrapalhando os alunos que tentavam usar o laboratório de informática. 
Quando o incitei a me dar direções sobre como me tornar mais bem informado e 
autossuficiente, ele me deu uma simples dica: mergulhe nos serviços de diretório, 
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aprenda uma distribuição UNIX, e domine uma linguagem de script. 

Ele escolheu trés habilidades para eu aprender, dentre as infinitas disponiveis. E, 
com a confiança que essa pessoa, quem eu considerava ser um mestre, as prescreveu, 
eu me dispus a aprender essas trés habilidades. Minha carreira desde entáo tem sido 
construída sobre o alicerce desses conhecimentos, todos os trés, os quais ainda sáo 
completamente relevantes para tudo. Eu fago isso. Näo € que o caminho que Ken 
me deu foi a resposta absolutamente certa - náo há respostas absolutamente certas. 
O importante é que ele estreitou a longa lista de habilidades que eu poderia estar 
aprendendo, transformando-a em uma curta lista de habilidades que eu, de fato, 
aprendi. 

O mentor também serve como alguém de confianga que pode observar e julgar 
suas decisóes e seu progresso. Se vocé é um programador, vocé pode mostrar seus 
códigos e obter indicadores. Se vocé está planejando fazer uma apresentagäo no 
escritório ou em alguma reuniáo de um grupo de usuários locais, vocé pode mostrá- 
la de antemáo para seu mentor para receber feedback. Um mentor é alguém em que 
vocé pode confiar o suficiente para perguntar “O que deveria ser diferente em mim 
enquanto profissional?”, porque vocé sabe que ele náo vai apenas criticá-lo, mas sim 
ajudá-lo a melhorar. 

Finalmente, assim como no jazz, vocé náo apenas cria uma ligacáo pessoal e de 
responsabilidades para com seu mentor, mas o inverso também acontece. Se meu 
papel, em um relacionamento, é ajudar alguém, eu invisto no sucesso dessa pessoa. 
Estou ajudando alguém ao longo de sua carreira, por um caminho que eu acredito 
ser o correto. Portanto, se o caminho leva ao sucesso, o sucesso é meu também. 

Isso cria incentivos por parte do mentor para que seus orientandos tenham su- 
cesso. Tipicamente, sendo mais experiente e já bem sucedida, uma pessoa em tal 
papel teria o respeito de uma significativa rede de pessoas. O mentor se torna um 
elo que reforça a conexão entre você e sua rede. A importância desse tipo de cone- 
xão não pode ser subestimada. Afinal, a frase “Não é o que você sabe. É quem você 
conhece” não é um clichê sem motivo. 

O grau de formalidade num relacionamento de mentor não é importante. Nin- 
guém precisa explicitamente pedir a alguém para ser seu mentor (embora não seja 
definitivamente uma coisa ruim se você o fizer). Na verdade, seu mentor pode nem 
saber que está fazendo esse papel para você. O que importa é que você tenha alguém 
de confiança e que admire, que possa proporcionar uma orientação à sua carreira e 


ajudar a afiar seu ofício. 


57 


Casa do Código 





Faca algo 


1) 
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Tutorie a si mesmo - todos nós queremos ter alguém para nos orientar, mas a 
realidade é que nem sempre vamos poder encontrar alguém a quem possamos 
dar esse papel. Eis um jeito de fazer uma automentoria. 


Pense na pessoa de sua área que vocé mais admira. Muitos de nós já possuem 
uma pequena lista pronta, pegando de algum momento de nossas carreiras. Pode 
ser alguém com quem tenha trabalhado, ou pode ser alguém cujo trabalho é ad- 
mirado. Liste os dez atributos mais importantes desse modelo a seguir. Escolha 
os atributos que sáo a razáo de vocé té-lo escolhido para esse papel. Tais atribu- 
tos podem ser de áreas específicas de habilidade, como amplitude de tecnologia, 
ou a profundidade de conhecimento sobre algum domínio. Ou, eles podem ter 
características mais pessoais, como a habilidade de deixar os membros da equipe 
tranquilos, ou a de ser um palestrante envolvente. 


Agora, ranqueie essas qualidades em ordem de importáncia, sendo que 1é o me- 
nos importante e 10, o mais importante. Vocé acabou de criar e destilar uma lista 
de atributos que vocé acha admiráveis e importantes. Esses sáo os caminhos nos 
quais vocé deve se empenhar para emular o modelo escolhido. Mas como esco- 
lher em qual focar primeiro? 


Adicione uma coluna à lista, e para cada item na lista, imagine como seu modelo 
iria avaliar você em uma escala de 1 a 10 (10 sendo o melhor). Tente realmente 
se colocar na mente de seu modelo e observar a si mesmo como se fosse uma 
terceira pessoa. 


Quando você tem os atributos, o ranking, e suas próprias avaliações, em uma co- 
luna final, subtraia sua classificação em cada fileira do nível de importância que 
você deu à coluna anterior. Se você ranqueou algo como 10 para o atributo mais 
importante de seu modelo, e sua própria avaliação foi 3, isso lhe dá uma priori- 
dade final de valor 7. Tendo preenchido esta coluna completamente, separando 
em ordem descendente, você terá uma lista das 10 áreas priorizadas em que você 


deve melhorar. 


Comece com os primeiros dois ou três itens, e formule uma lista de tarefas con- 
cretas que você pode começar a fazer agora para melhorar a si mesmo. 


CAPÍTULO 14 


Seja um mentor 


Se vocé quer realmente aprender alguma coisa, tente ensiná-la para outra pessoa. 
Não tem jeito melhor de aperfeiçoar seu entendimento de algo do que se forçar a 
passá-lo para outras pessoas, para que eles possam entender. O simples ato de falar 
é um elixir conhecido para clarear a mente. Falar para bonecos e outros objetos 
inanimados é uma forma de resolver problemas bastante conhecida do folclore do 
desenvolvimento de software. 


Para descobrir se vocé realmente sabe algo, tente ensinar para outra pessoa. 


Eu vi Martin Fowler dar uma palestra em uma sala de desenvolvedores em Ban- 
galore, na qual ele dizia que toda vez que ele realmente quer aprender algo, ele escreve 
sobre isso. Martin Fowler é um conhecido desenvolvedor de softwares e autor. Pode- 
mos dizer que ele é um dos mais bem conhecidos e influentes professores que essa 
indústria tem a oferecer, se considerarmos que seu papel enquanto autor é aquele de 
um professor remoto e mentor. 
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Aprendemos ensinando. É irónico, porque esperamos que um professor já saiba 
de tudo. Claro, eu náo quero dizer que podemos aprender completamente algo ensi- 
nando outra pessoa. Mas conhecer os fatos náo é o mesmo que entender suas causas 
e ramificagöes. É o tipo de conhecimento mais profundo que desenvolvemos ao en- 
sinar a alguém. 

Procuramos analogias para explicar conceitos complexos, enquanto tentamos 
entender porque algumas analogias que parecem funcionar, na prática náo funcio- 
nam. Já outras que parecem menos efetivas, acabam sendo melhores. 

Quando vocé ensina, vocé precisa responder questóes nas quais vocé pode nunca 
ter pensado. Por meio do ensino, nós limpamos os cantos sujos do nosso conheci- 
mento, que raramente sáo expostos. 

Portanto, assim como vocé pode se beneficiar encontrando um mentor, vocé 
pode se beneficiar sendo um mentor para outra pessoa. 

Mentoria traz efeitos sociais positivos também. Um grupo de mentores e seus 
orientandos cria uma rede social firme e poderosa. A ligacáo mentor-orientando é 
bastante forte, de modo que os lagos dessa rede profissional seja mais forte do que 
aqueles relacionamentos passivos. Quando vocé está em uma relacáo de mentoria 
com alguém, vocé forma uma alianca um com o outro. Uma rede desse tipo € um 
ótimo lugar para fazer circular problemas difíceis ou procurar por trabalho. 

Vocé também náo deveria subestimar que simplesmente faz sentir bem ajudar 
as pessoas. Se vocé pode manter em mente os interesses de outros, terá realmente 
feito algo altruísta com suas habilidades. No incerto ambiente económico de hoje, 
ajudar de fato alguém é um trabalho do qual vocé náo pode ser demitido. E é pago 
com uma moeda que não desvaloriza com inflação. 

Você não encontra um orientando saindo por aí e se autodeclarando um guru, 
mas sim sendo conhecido e disposto a compartilhar seu conhecimento paciente- 
mente. Não se preocupe se você não é um expert absoluto em algum tópico. As 
chances são de que há algo em que você tem experiência e que o qualificaria para 
ajudar alguém menos experiente. Encontre esse algo e comece a ser prestativo. 

Você pode, por exemplo, ter feito uma considerável quantidade de trabalhos em 
PHP Você poderia ir até seu grupo local de usuários PHP e oferecer ajuda aos usuá- 
rios menos experientes com seus problemas específicos. Ou, se você não tem um 
lugar disponível para fornecer mentoria presencial, você poderia simplesmente co- 
meçar a responder perguntas em um fórum de discussões online ou em um canal 
IRC, ou ainda ajudar pessoas a fazer debug nos problemas de suas aplicações. Entre- 
tanto, mantenha em mente, que mentoria diz respeito a pessoas. Um relacionamento 
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de mentoria online nunca pode ser comparado ao que acontece entre dois seres hu- 
manos no mesmo local. 

Vocé náo precisa montar um relacionamento de mentoria formal para obter esses 
benefícios. Apenas comece a ajudar pessoas, e o resto virá automaticamente. 


Faca algo 


1) Procure alguém para carregar sob suas asas. Vocé pode encontrar alguém mais 
jovem e menos experiente em sua empresa, talvez um estagiário. Ou, vocé po- 
deria conversar com os departamentos de ciéncia da computagäo ou sistemas de 
informação em sua universidade local e se voluntariar para orientar um estudante 


da faculdade. 


2) Encontre um fórum online e escolha um tópico. Comece a ajudar. Torne-se co- 
nhecido por seu desejo e por sua habilidade de pacientemente ajudar pessoas a 
aprender. 
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CAPÍTULO 15 


Pratique, pratique, pratique 


Quando eu estudava música, eu passava longas noites no prédio de música da mi- 
nha universidade. Pelas finas paredes das salas de estudo da universidade, eu ficava 
imerso em algum dos sons musicais mais feios imagináveis. Náo é que os músicos 
da minha escola eram ruins. Muito pelo contrário. Mas eles estavam praticando. 

Quando vocé treina música, ela náo deveria soar boa. Se vocé sempre soa bem 
durante as sessóes de estudo, significa que vocé náo está estendendo seus limites. É 
para isso que serve a prática. O mesmo é válido para os esportes. Atletas se esforçam 
até o limite durante os exercícios, de modo que eles possam expandir tais limites para 
as performances reais. Eles deixam a “feiura” acontecer nesse momento de prática - 
e náo quando eles estáo realmente trabalhando. 

Na indústria da computação, é comum encontrar desenvolvedores que forçaram 
seus limites. Infelizmente, esse é geralmente um caso de um desenvolvedor sendo 
subqualificado para as tarefas que ele assumiu. Nossa indústria tende a praticar no 
emprego. Você consegue imaginar um músico profissional subindo ao palco e re- 
plicando os sons inarticulados das salas de estudo da minha universidade? Isso não 
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seria tolerado. Músicos sáo pagos para apresentar em público - náo para praticar. 
Similarmente, um lutador de artes marciais ou um boxeador estressando o-se até a 
fadiga durante os combates náo iria muito longe no esporte. 

Como indústria, nós devemos criar tempo para a prática. Nós do ocidente fre- 
quentemente tomamos partido de programadores domésticos, baseados na quali- 
dade relativamente alta do código que eles produzem versus a de times offshore. Se 
vamos tentar competir com base na qualidade, temos que parar de tratar nosso em- 
prego como uma sessáo de prática. Temos que investir o tempo em nossa profissäo. 

Muitos anos atrás, eu comecei a experimentar exercícios de programação mo- 
delada após minhas sessões de prática de música. A regra número um era que o 
software que eu estava desenvolvendo não poderia ser algo que eu desejava usar. Eu 
não queria limpar os cantos na pressa, por conta de um objetivo final. Então eu es- 
crevia softwares que não eram úteis. 

Eu não me preocupava com os cantos, mas estava frustrado ao descobrir que 
muitas das ideias que tive durante a prática não estavam funcionando. Embora eu 
estivesse tentando fazer tão bem quanto se fosse pra valer, na medida do possível, os 
designs e códigos que eu criava não eram tão elegantes quanto eu queria que fossem. 

Olhando para trás agora, vejo que o estranho sentimento que eu tive com essas 
experiências era um bom sinal. Meu código não estava completamente desprovido 
de momentos brilhantes. Mas eu estava esticando meus músculos mentais e cons- 
truindo meus pedaços de código. Assim como para tocar o saxofone, se eu sentasse 
para praticar e só saíssem sons bonitos, eu saberia que não estava praticando. Da 
mesma forma, se eu sentasse para praticar os códigos e só viessem códigos elegan- 
tes, eu estaria provavelmente em algum lugar próximo ao centro das minhas atuais 
capacidades, em vez de no limite, aonde uma boa sessão de treinamento deveria me 
levar. 


Pratique nos seus limites. 


Portanto, como você sabe o que praticar? O que estende seus limites? O assunto 
de como praticar poderia facilmente dar um livro só pra isso. Como um começo, 
eu vou pegar emprestado mais uma vez da minha experiência como um músico de 
jazz. Eu dividia o estudo de jazz nas seguintes categorias (simplificadas para os não 
músicos): 


e Físico / coordenação; 
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e Leitura à primeira vista; 


e Improvisacáo; 


Isso deve servir como um quadro de uma das maneiras de como um desenvol- 
vedor deve praticar. 

Físico / coordenagäo: músicos devem praticar os aspectos técnicos de seus ins- 
trumentos. Produção de som, coordenação física (fazer os dedos se moverem com 
agilidade, por exemplo), velocidade e precisáo. Tudo isso é importante. 

O que nós, desenvolvedores de software, temos desses fundamentos de música? 
E quanto aos cantos sujos de sua primeira linguagem de programação que você rara- 
mente visita? Por exemplo, a linguagem que vocé usa suporta expressöes regulares? 
Expressöes regulares sáo um recurso extremamente poderoso e subutilizado de mui- 
tos ambientes de programacáo. A maioria dos desenvolvedores náo as usa quando 
poderia, porque náo possui o nível de habilidade necessário para serem produtivos 
com elas. Como resultado, um monte de código de manipulacáo de strings é criado 
e, portanto, exige maior manutencäo. 

As mesmas regras se aplicam para as APIs de sua linguagem. Se vocé náo tiver as 
várias ferramentas do ambiente sob seus dedos (como dizem os músicos), é pouco 
provável que vocé as use quando elas realmente o poderiam ajudar. Tente verdadei- 
ramente mergulhar em, por exemplo, como programagäo multi-threaded funciona 
na sua linguagem. Ou, e quanto às bibliotecas, APIs pra programar aplicações em 
rede, ou mesmo o grupo de funcionalidades disponíveis para trabalhar com cole- 
ções ou listas? A maioria das linguagens de programação modernas oferece ricas e 
poderosas bibliotecas em todas essas áreas, mas desenvolvedores tendem a apren- 
der uma pequena parcela, com a qual eles podem, menos eficientemente, escrever o 
mesmo código que eles teriam escrito se tivessem dominado o todo o conjunto de 
ferramentas. 

Leitura à primeira vista: especialmente como um músico de estúdio, a habili- 
dade de ler e executar música quase perfeitamente na primeira tentativa é suprema 
para um profissional. Uma vez eu toquei saxofone em um jingle para a Blockbuster 
(a videolocadora). Eu toquei ambas as partes principais e secundária de saxofone 
alto em uma música que tinha um ritmo bem rápido. Quando a fita começou a to- 
car, era a primeira vez que eu via aquela música. Tocamos uma vez a parte principal 
e outra a parte secundária. Qualquer erro, e a banda inteira teria de fazer tudo de 
novo - e isso aumentaria o custo de horas no estúdio. 
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Para desenvolvedores, o que significaria ser capaz de ler um código ao vé-lo? Ou 
especificações de requisitos ou designs? Um excelente lugar para encontrar novos 
códigos com os quais praticar é a comunidade open-source. Você tem algum biblio- 
teca open-source de que goste? E se você tentar adicionar uma nova funcionalidade 
nela? Vá procurar na lista de tarefas a fazer dessa biblioteca, e force a si mesmo a 
dedicar uma considerável parcela de tempo para implementar isso (ou, pelo menos, 
determinar o que é necessário para implementá-la). 

Depois de escolher uma biblioteca, baixe seu código-fonte, e comece a explorar. 
Como você sabe onde procurar? Quais truques você usa para se achar em uma base 
de código relativamente grande? Por onde começa? 

Esse é um exercício que você pode fazer com frequência e em curtos períodos 
de tempo. Você não necessariamente deve implementar a funcionalidade. Apenas 
a use como um ponto de partida. O verdadeiro objetivo é entender o que você está 
visualizando o mais rápido possível. Certifique-se de variar os softwares com os quais 
você trabalha. Tente diferentes tipos de software em diferentes estilos e linguagens. 
Anote os pontos que facilitam ou dificultam a você se encontrar no código. Quais 
padrões você está desenvolvendo que o ajudam a trabalhar no código? Quais rastros 
você deixa para si mesmo para o ajudar a navegar conforme você sobe ou desce nas 
camadas dessa funcionalidade? 

Improvisação: improvisação é pegar alguma estrutura ou restrição e criar algo 
novo, em tempo real, sobre essa estrutura. Como programador, eu me descobri fa- 
zendo mais improvisos em momentos de estresse. “Oh não! O servidor da rede 
sem fio caiu, e nós estamos perdendo pedidos!” É aí que algumas das mais criativas 
improvisações acontecem. É aí que você faz coisas loucas, como recuperar dados 
perdidos manualmente resubmetendo pacotes sobre uma rede sem fio a partir de 
um arquivo binário. Ninguém o pediu pra fazer essas coisas, especialmente não no 
calor do momento. Esse tipo de habilidade de programação afiada e rápida pode ser 
como um poder mágico quando usada no momento certo. 

Uma ótima maneira de afiar a mente e melhorar suas habilidades de improvisar 
códigos é praticar com restrições autoimpostas. Pegue um simples programa, e tente 
escrevê-lo com essas restrições. Meu exercício favorito é escrever um programa que 
mostra a letra da velha canção “99 Bottles of Beer on the Wall”. Como você pode- 
ria escrever tal programa sem atribuir variáveis? Ou, o quão curto você consegue 
escrever o programa, de modo que ele ainda exiba a letra corretamente? Para uma 
restrição adicional, quão rápido você pode escrever esse programa? Que tal praticar 
problemas pequenos e difíceis com um timer? 
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Essa é apenas uma perspectiva limitada sobre como praticar. Vocé pode pegar 


exemplos de qualquer área, das artes visuais até prática de religião. O que importa é 


encontrar suas próprias necessidades e certificar-se de que vocé náo está praticando 


durante suas apresentacóes (no emprego). Vocé deve reservar um momento para 


praticar. É sua responsabilidade. 


Faca algo 


1) 


TopCoder - http://topcoder.com é um renomado site de competição de progra- 
mação. Você pode registrar uma conta e competir online por prêmios. Mesmo se 
vocé náo se interessa em competir com outros, o TopCoder oferece uma sala de 
treinamento com uma grande coleção de exercícios que podem ser usados como 
uma excelente base para suas sessóes de estudo. Vá se registrar e faga uma tenta- 
tiva. 


Code Kata - Dave Thomas, um dos Pragmatic Programmers (o editor deste livro 
no original), transformou a ideia de praticar código em algo... bem, pragmático. 
Ele criou uma série do que ele chama de Code Kata, que sáo pequenos exercicios 
que estimulam o pensamento que os programadores podem fazer na linguagem 
de sua escolha. Cada kata enfatiza uma técnica específica ou processo de pensa- 
mento, provocando uma flexáo concreta de seus músculos mentais. 


No blog http://codekata.pragprog.com, Dave disponibiliza gratuitamente diver- 
sos katas. Lá, vocé também encontra links para uma lista de e-mail e para as 
solucóes de outros usuários, junto da discussáo sobre como foram resolvidos. 


Seu desafio: trabalhe com os katas. Mantenha um diário (ou talvez um blog) 
das suas experiéncias com eles. Quando terminar, escreva seu próprio kata e 
compartilhe. 
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CAPÍTULO 16 


O jeito que vocé faz 


“Desenvolver software” náo é uma coisa, um substantivo. Do contrário, “desenvolver 
software” é um termo; é o processo de criar uma coisa. Quando estamos codificando, 
é táo importante focar no processo utilizado quanto focar no produto que está sendo 
desenvolvido. Se vocé tirar os olhos do processo, estará arriscando entregar atrasado, 
ou entregar o produto errado, ou mesmo náo entregar. Esses resultados tendem a ser 
desprezados pelos clientes. 

Felizmente, muita atengäo tem sido dada ao processo de criar um bom software 
(e produtos em geral). Muito dessas técnicas foram catalogadas em um grupo de 
metodologias, que sáo tema de vários livros. 

Infelizmente, a maioria dos desenvolvedores náo se beneficia dessa boa informa- 
ção. Para a maior parte das equipes, o processo é uma reflexão tardia ou algo imposto 
de cima. O termo metodologia, em suas mentes, se tornou sinónimo de papelada e 
longas e insignificantes reunióes. Muito frequentemente, a metodologia é algo que 
seus chefes impóem. 


Os gerentes intuitivamente sabem, que eles precisam seguir algum tipo de pro- 
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cesso, mas geralmente náo sabem sobre as opgöes que agora estáo disponiveis. Como 
resultado, eles tiram a poeira dos mesmos processos que lhes foram impostos na dé- 
cada de 80, os envolvem com uma fita de chavóes compatíveis (a fita com tons pastéis 
Agile é uma boa escolha nesse momento), e passam a prática para seus times. E, ao 
menos que alguém quebre o ciclo realmente pesquisando o que funciona e o que náo, 
o mesmo processo acontecerá outras vezes, conforme os desenvolvedores da equipe 
tornam-se gerentes. 

Talvez vocé esteja pensando que deve existir um jeito melhor de desenvolver 
software. E para a maioria das equipes, existe. 

Se vocé é um programador, testador, ou designer de software, vocé pode pensar 
que o processo do desenvolvimento náo é sua responsabilidade. Infelizmente, geral- 
mente náo é responsabilidade de ninguém. Se for designado a alguém, pode cair no 
buraco negro, também conhecido como “grupo de processo”. A verdade é que, para 
um processo de software ter alguma chance de ser implementado com sucesso, ele 
deve ser compreendido pelas pessoas que o estáo usando - pessoas como vocé. 

A melhor maneira de compreender e dominar esses processos é ajudar a 
implementá-los. Se sua empresa náo possui um processo, pesquise metodologias 
que podem funcionar para vocés. Tenha almocos com sua equipe para discutir os 
atuais problemas de desenvolvimento, e sugira que adotar um processo padráo pode 
mitigá-los. Reina um plano de colocar em ação o processo escolhido na sua empresa 
e obtenha a aprovação de todos. Então comece a implementar seu plano. 


Se vocé quer sentir que é dono de um processo, ajude a implementá-lo. 


Alternativamente, vocé talvez trabalhe em um ambiente em que o processo é 
passado de cima para baixo. No momento em que as ideias chegam ao time de de- 
senvolvimento, as práticas foram diluídas e reinterpretadas, até o ponto em que se 
tornam irreconhecíveis das originais. Lembra-se da brincadeira de telefone-sem-fio? 

Mais uma vez, essa é uma oportunidade de tomar a iniciativa. Pesquise a meto- 
dologia que introduziram, e ajude a interpretar o que ela realmente significa, tanto 
para seu time como para sua geréncia. Vocé náo poderá contestar que um processo 
foi imposto, entáo vocé deve fazé-lo funcionar fazendo o correto. 

O mundo da metodologia pode rapidamente comegar a parecer uma concha oca 
de chavöes. Mas, como podem ser chavóes compativeis, vocé sempre pode apren- 
der alguma coisa do estudo de um processo de software - mesmo se essa coisa é 0 
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que náo fazer. Se vocé entender bem do processo de software, poderá fazer uma 
argumentagäo mais confiável sobre como sua equipe deveria estar trabalhando. 

Mesmo com a abundáncia de metodologias para escolher, é bem difícil que vocé 
trabalhe para uma empresa que implemente uma delas inteiramente. Tudo bem. O 
melhor processo a se seguir é o que torna sua equipe mais produtiva e que resulta 
em melhores produtos. 





METODOLOGIAS: NÁO SÓ PARA GEEKS 


Embora o gerenciamento de projetos náo seja necessariamente ligado 
a metodologia de desenvolvimento de software, vocé pode dar de cara 
com as técnicas de gerenciamento de projetos da sua empresa. Numero- 
sas metodologias de gerenciamento de projetos estáo em uso por toda in- 
dústria de tecnologia. Provavelmente, o mais notável é o Project Manage- 
ment Book of Knowledge (http://www.pmi.org) , do Project Management 
Institute, com seu programa de certificacáo, que é bastante reconhecido. 

Six Sigma (http://www.isixsigma.com) é outra metodologia de qua- 
lidade náo específica de software. Dirigida por empresas como General 
Electric e Motorola, a abordagem da Six Sigma enfatiza a medição e a 
análise dos processos e produtos para conduzir à satisfação do cliente e à 
eficiência. Embora não sejam específicas para desenvolvimento de soft- 
ware, a abordagem rigorosa e metódica da Six Sigma oferece várias lições 
que são diretamente aplicáveis à sua função como programador. 











O único modo de descobrir essa epifania reveladora é estudar as opções dispo- 
níveis, escolher as peças que fazem sentido para você e sua equipe, e continuamente 
refiná-las baseando-se nas suas experiências. 

Em último caso, se você não pode implantar o processo, você não consegue fazer 
o produto. É muito mais fácil encontrar alguém que pode fazer o software funcionar 
do que encontrar alguém que faça o making of do software funcionar. Portanto, adi- 
cionar conhecimento do processo de desenvolvimento de software para seu arsenal 
apenas vai ajudá-lo. 


Faça algo 


1) Escolha uma metodologia de desenvolvimento de software, e escolha um livro, 
comece a ler sites e inscreva-se em uma lista de e-mails. Olhe para a metodologia 
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com um olho crítico. Quais vocé acha que seriam seus pontos fortes e fracos? 
Em seguida, faça o mesmo para outra metodologia. Contraste suas vantagens e 
desvantagens. Como vocé poderia combinar suas abordagens? 


CAPÍTULO 17 


Nos ombros dos gigantes 


Quando eu tocava jazz, eu ficava muito tempo ouvindo música. Eu náo apenas co- 
locava música de fundo enquanto eu lia ou dirigia. Eu realmente ouvia a música. Se 
a improvisacáo no jazz significa executar o que vocé escuta por cima dos acordes de 
uma música, entáo realmente ouvir a música é uma fonte de inspiragäo e conheci- 
mento do que funciona e do que não. O que soa ótimo é apenas o que se encaixa 
lá. 

A enorme história do jazz serve como uma incrível fonte de conhecimento, para 
qualquer um com a habilidade de ouvi-las. Ouvir música, portanto, náo é uma ati- 
vidade passiva para um músico de jazz. É um estudo. Mais ainda, a habilidade de 
entender o que vocé está ouvindo é uma proficiéncia que se desenvolve ao longo do 
tempo. Meu círculo de amigos músicos realmente faziam esse tipo de audicäo expli- 
citamente. Tínhamos festas para ouvir músicas, em que um grupo de músicos geeks 
de jazz se sentavam e ouviam música, para depois discuti-la. Ás vezes, jogávamos 
“Nomeie o improvisador”, no qual um de nós tocava uma gravacáo de um solo im- 
provisado e o resto deveria adivinhar, baseado no estilo, quem havia gravado aquele 
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improviso. 

Nós do mundo do jazz náo éramos especiais, claro. Compositores de música 
erudita fazem a mesma coisa. Assim como romancistas e poetas. Assim como escul- 
tores e pintores. Estudar a obra dos mestre é uma parte essencial para se tornar um 
mestre. 

Quando ouviamos as gravações de jazz, discutiamos os artifícios musicais que 
os improvisadores usavam para comunicar seus pontos musicais. “Uau! Vocé ouviu 
como ele comecou contornando no final da estrutura?” ou “Foi realmente estranho 
o jeito que ele estava tocando atrás do compasso”. Essas discussóes nos ajudavam 
a investigar e descobrir truques que podíamos levar para tentar na nossa próxima 
sessáo de improvisacáo. 


Minere os códigos existentes para ter insights. 


Design de software e programação têm muito em comum com as artes, guarda- 
das as devidas particularidades. Podemos investigar uma base de código grande para 
encontrar padrões e truques. O movimento dos design patterns (veja Design Patterns 
[3]) é focado na descoberta e na documentação de soluções reusáveis para problemas 
comuns de desenvolvimento de software. Design patterns formalizaram o estudo de 
códigos existentes, tornando a prática acessível a um grande número de profissionais 
de software. Ainda assim, eles abrangem apenas um pequeno subconjunto dos tipos 
de técnicas que podemos aprender através da leitura de código. 

Como outros programadores resolvem problemas? Como outros usam estrategi- 
camente variáveis, funções e nomenclatura? Se eu quisesse implementar o protocolo 
Jabber, como eu poderia fazê-lo? Quais maneiras criativas eu poderia achar para li- 
dar com a comunicação entre processos, entre UNIX e sistemas Windows? Esses são 
o tipo de questões que você pode responder através do estudo de códigos existentes. 


Use código existente para refletir sobre suas próprias capacidades. 


Ainda mais importante que encontrar soluções para problemas específicos é o 
uso de códigos de outros desenvolvedores como uma lente de aumento para inspe- 
cionar nossos próprios estilos e capacidades. Assim como escutar uma gravação de 
John Coltrane sempre me lembrava de onde eu me estava na escala de habilidades 
de um saxofonista; ler o código de um ótimo desenvolvedor possui um efeito humi- 
lhante. Entretanto, não se trata apenas de se sentir humilhado. Conforme você lê 
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o código, vocé encontrará coisas que nunca teria feito. Encontrará coisas que vocé 
pode nunca ter imaginado. Por qué? Em que o desenvolvedor estava pensando? 
Quais foram suas motivações? Você pode até aprender com códigos ruins neste tipo 
de exploração crítica de autoconhecimento a partir do trabalho de alguém. 

O ato de aprender a partir do trabalho que veio antes de você funciona bem no 
mundo das artes, porque não há recursos escondidos para uma pintura ou uma peça 
de música. Se você pode ouvir a música ou ver a obra de arte, você pode aprender 
dela. Felizmente, como desenvolvedores de software, temos acesso a praticamente 
uma infinita série de softwares existentes no mundo open source. 

Há tantos open sources disponíveis que seria impossível realmente ler todos. De- 
finitivamente há projetos open source ruins, mas também há alguns ótimos. Existe 
código open source disponível para implementar quase qualquer tarefa que pode ser 
feita com software em quase todas as linguagens de programação disponíveis. 

Conforme você olha para esse código com um olhar crítico, você começa a de- 
senvolver seus próprios gostos, assim como seria com música, arte ou literatura. Di- 
versos estilos e artifícios vão entretê-lo, impressioná-lo, deixá-lo bravo, e (eu espero) 
desafiá-lo. Se você realmente estiver procurando por eles, encontrará algum truque 
que o torne mais produtivo com relação a paradigmas de design, mudando comple- 
tamente o jeito como você resolve problemas. Assim como nas artes, estudando e 
aprendendo com os hábitos dos outros, você desenvolverá seu próprio estilo distin- 
tivo de desenvolvimento de software. 

Um efeito colateral positivo de leitura de código é que você vai aprender mais 
sobre o que já existe. Quando você tem um novo problema que precisa de solução, 
você deve se lembrar que “Oh, eu vi uma biblioteca que faz manipulação de MIME 
naqueles projetos”. Se os termos de licença estão certos, você pode economizar bas- 
tante tempo, e sua empresa, bastante dinheiro, ao se tornar mais ciente do que já 
está lá fora para ser usado. Você pode se surpreender ao perceber quanto dinheiro é 
gasto na indústria de software para reimplementar a roda (invenção seria uma pala- 
vra muito generosa) mais e mais vezes. 

Sir Isaac Newton disse: “Se vi mais longe, foi porque eu subi nos ombros dos gi- 
gantes”. Pessoas espertas como Newton sabem que há muito o que aprender daqueles 
que vieram antes de nós. Seja como Newton. 


Faça algo 


1) Escolha um projeto e o leia como um livro. Faça anotações. Esboce as coisas boas 
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e ruins. Escreva uma crítica e a publique. Ache pelo menos um truque ou padráo 
dele que vocé possa usar. Encontre pelo menos uma coisa ruim que vocé obser- 
vou que acrescentará a sua lista do que náo fazer quando estiver desenvolvendo 
software. 


Encontre um grupo de pessoas com a mentalidade parecida com a sua e se reúna 
com eles uma vez por més. A cada sessáo alguém indica algum trecho de código 
para ser estudado, de 2 a 200 linhas. Quebre o código e discuta o que está por 
trás dele. Pense nas decisóes que levaram a ele. Pondere sobre o código que náo 
está lá. 


CAPÍTULO 18 


Automatize-se em um emprego 


Um assunto constante na minha carreira tem sido o conflito entre o desejo das áreas 
gerenciais de TI em contratar empresas de consultoria com baixo custo (geralmente 
offshore) para fazer o trabalho e minha forte crença de que o desenvolvedor mais 
barato geralmente náo leva a um custo mais baixo. Eu já tive várias conversas ten- 
sas com diretores e vice-presidentes, argumentando de forma apaixonada sobre as 
vantagens de contratar poucos desenvolvedores que sejam realmente bons em vez de 
uma legiáo de pessoas de baixo custo e de habilidades fracas. 

Infelizmente, em geral eu era interrompido no meio da minha argumentacáo. O 
problema da minha posigäo náo é que eu estava errado (obviamente!). É que náo 
há uma maneira fácil de provar que estava certo. E, a partir de uma perspectiva de 
custo, a única evidência concreta que temos leva à conclusão de que um baixo custo 
por hora é, de fato, vantajoso para a empresa. 

Imagine um projeto de software hipotético para algum domínio que vier à sua 
mente. Quantos programadores são necessários para escrever um software como 
este em três meses? Cinco, você diz? Seis? OK, e quanto ao mesmo projeto em dois 
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meses? Como vocé diminui um més? 

O gerenciamento padräo de TI diz que vocé adiciona programadores para ir mais 
rápido. É errado, mas é nisso que as pessoas acreditam. E se vocé consegue fazer um 
projeto simples ir mais rápido ao adicionar programadores, a conclusáo desta regra 
é a de que mais gente significa maior produtividade. Mas há mais de uma maneira 
de conseguir isso. Se a meta é aumentar a taxa de desenvolvimento de software, vocé 
pode: 


e Conseguir pessoas mais rápidas para fazer o trabalho; 
e Conseguir mais pessoas para fazer o trabalho, ou; 


e Automatizar o trabalho. 


Uma vez que ainda náo se sabe como verdadeiramente medir a produtividade 
de desenvolvimento de software, é difícil provar que uma pessoa é mais rápida que 
outra. Entáo, gerentes de finangas se focam no custo por hora. 


Isso leva a uma simples fórmula, que assume um período de tempo fixo: 


ai Nümero de projetos 
Produtividade = 
Numero de programadores x Taxa horäria 


Em alguns ambientes, é realmente possivel calcular a produtividade real de um 
time de software. Na maior parte, vocé vai encontrar medidas maleáveis e amorfas 
como número de projetos ou número de requerimentos, sem nenhuma possibili- 
dade de repetir a medição dessas unidades. 

Logo, a abordagem do programador mais rápido é muito difícil de se provar, 
e nós náo queremos encorajar a abordagem de se adicionar mais programadores 
baratos. Isso nos leva a uma automação. 

Eu me lembro do sensacionalismo em relação à perda de emprego nos Estados 
Unidos na década de 80. Naquela época, não apenas estávamos culpando outros 
países, mas também culpávamos as máquinas e, especificamente, computadores. Gi- 
gantescos braços robotizados estavam sendo instalados em indústrias. Eles podiam 
bater o trabalho dos humanos tanto em rendimento quanto em precisão, o que indica 
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que nem valia a pena compará-los. Todo mundo estava chateado — todo mundo, isto 
é, com exceção das pessoas que criaram os braços robotizados. 

Imagine que sua empresa seja do ramo de criação de websites para pequenas em- 
presas. Você basicamente precisa criar o mesmo site repetidas vezes, com contatos, 
pesquisas, carrinhos de compra, os serviços. Ou você poderia contratar um pequeno 
número de programadores realmente rápidos para construírem os sites para você, 
ou contratar vários programadores com custo baixo para fazer a coisa toda manual- 
mente e repetitivamente, ou, em vez, criar um sistema para gerar os sites. 

Se colocarmos alguns números (inventados) na fórmula do gerente de finanças, 
temos as equações mostradas na Figura 18.1. 

Automação faz parte do DNA de nossa indústria. Ainda assim, por alguma ra- 
zão, tendemos a não automatizar nosso trabalho. Como você poderia comprovada- 
mente fazer softwares melhores, mais rápidos e mais baratos do que seu concorrente 
offshore? Faça os robôs; Automatize-se em um emprego. 


Programadores rápidos 
5 


— = 0,02 
3 x $80 


Programadores baratos 
5 


—— = 0,02 
20 x $12 


Um programador + 
um braço robótico 


Figura 18.1: Comparação de produtividade 


De consultor de TI para diretor administrativo 


por Vik Chadha 


Minha jornada de deixar de ser um consultor de TI na GE para ser empresário 
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na bCatalyst (um aceleradora de negócios com um capital de 5 milhóes de dólares) 
náo foi um caminho que eu tinha pensado como o próximo passo de minha carreira. 

Então, como foi que eu fiz a transição de trabalhar para uma das 5 principais 
empresas no ranking da revista Fortune, com dezenas de milhares de funcionários, 
para trabalhar em uma empresa que orientava e investia em startups de tecnologia 
em estágio inicial? Quando eu olho para trás e tento ligar os pontos, alguns padróes 
importantes emergem, e eu gostaria de compartilhá-los com vocé, com a esperanga 
de que vocé possa adaptá-los para o seu contexto. 

Logo depois de terminar meu mestrado em engenharia da computagäo e elétrica 
na Virginia Tech, eu entrei na GE como um consultor. O uso comercial da internet 
estava começando a avançar em passos largos, e eu trabalhei em vários projetos para 
fazer a plataforma mais incrível e poderosa, junto de suas tecnologias internas, pro- 
gredindo rapidamente começando pela equipe de finanças de TI, passando para o 
grupo de serviços e tecnologia, para a automação de vendas, e finalmente, para os 
dados de venda do grupo de depósito, trabalhando em cada equipe para desenvolver 
novas iniciativas. Eu adorava pesquisar, e com isso, pegar as mais novas tecnologias 
e aplicá-las para resolver problemas complicados. 

Entretanto, viver nessa área de novidades da tecnologia nem sempre era diver- 
tido. Nós invariavelmente tínhamos problemas com tecnologias que ainda não es- 
tavam prontas para serem usadas, e gastávamos muito tempo e energia ajudando os 
seus donos a debugarem seus produtos. Do ponto de vista do cliente, eu aprendi 
que não importa quão legal a tecnologia seja, ela só terá valor se resolver um pro- 
blema real. Ao longo do tempo, isso me ajudou a mudar a maneira de pensar, de ser 
centrado em tecnologia para ser centrado em solução. Perceber essa nova forma de 
pensar foi muito valioso para avaliar as startups de tecnologia em estágio inicial na 
bCatalyst, alguns anos depois. 

Contudo, por mais que eu gostasse de trabalhar na GE, um aspecto importante 
estava faltando. Eu senti que, na minha função como um profissional de TI, eu estava 
basicamente desenvolvendo todas minhas habilidades em uma única dimensão, sem 
ter a oportunidade de realmente entender como as empresas funcionam, como elas 
fazem dinheiro, o que as tornam sustentáveis, e como elas inovam. Em vez de ficar 
frustrado, eu decidi tomar a iniciativa e fazer algo a respeito disso, aprendendo mais 
sobre negócios e empreendedorismo. Eu nunca fiz nenhum curso de negócios e sabia 
que o único jeito para eu aprender os detalhes do que é preciso para começar uma 
empresa era colocando a mão na massa (isto é, aprender por meio de tentativas e 
erros). 
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Um ex-colega de quarto e empreendedor, que também era um amigo próximo 
(Raj Hajela), minha esposa (Vidya), e eu elaborávamos ideias tentando descobrir 
onde havia necessidades insatisfeitas no mercado. Nós queríamos explorar as opor- 
tunidades de e-commerce, mas náo queríamos vender nada que fosse uma mercado- 
ria. Nós tinhamos um interesse real, e um conhecimento prévio em artes e gostáva- 
mos do fato de que cada obra de arte era única em sua natureza. Meu tio durante 
a vida toda foi um artista que lutou para se sustentar com isso. Fizemos algumas 
pesquisas e concluímos que este era o caso da maioria dos artistas. Então decidimos 
resolver esse problema criando uma plataforma que ajudasse os artistas para que pu- 
dessem publicar e promover seus trabalhos, além de manter contato com seus con- 
sumidores. Com essa missão em mente, lançamos o Passion4Art.com e começamos 
o trabalho pesado de conseguir artistas para se juntarem ao nosso site e colocarem as 
imagens digitais de suas pinturas online. Depois que inscrevemos os primeiros 1000 
artistas, e eles conseguiram montar seus próprios websites, acreditamos que estáva- 
mos dando alguma coisa de valor, e passamos a procurar por investimento externo. 

Naquela época (cerca de 1999), uma empresa chamada eMazing.com fornecia 
dicas diárias sobre uma variedade de assuntos, e nós achamos que podíamos fazer 
parceria com eles (trabalhando com nossos artistas e o canal de distribuição deles), 
para fornecer um Art Tip of the Day (dica de arte do dia). Um dos chefes executivos 
se reuniu conosco, aprovou o que tínhamos a oferecer e concordou em fazer uma 
tentativa. 

Falamos pra ele que estávamos procurando investimento para construir nossa 
infraestrutura, e ele gentilmente se encarregou de enviar nosso plano de negócios 
para um novo acelerador de negócios na cidade, chamado bCatalyst. 

Poucos dias depois, recebemos uma ligação de Keith Williams, o CEO da bCa- 
talyst, informando-nos que eles tinham interesse em nos encontrar pessoalmente 
e saber mais sobre nossas intenções. Estávamos obviamente empolgados com essa 
reunião. Eu não percebi até muito tempo depois o quão importante era o fato de eles 
terem ouvido sobre nós de uma fonte confiável. A lição aqui é que se você precisar 
entrar em contato com um investidor de risco, trabalhe duro para conseguir uma 
boa indicação, já que esta é a melhor maneira de abrir portas. 

Ao longo das várias reuniões que tivemos com Keith, percebemos que havia uma 
boa química entre nossos times, mas a bolha da internet havia recentemente estou- 
rado, e o momento não era bom para eles fazerem um investimento nessa área. Con- 
tudo, eles nos disseram que se trouxéssemos outra ideia da qual eles gostassem, não 
hesitariam em nos apoiar. Eu perguntei-lhes se essa era uma maneira educada de 
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se dizer “näo” ou se eles estavam falando sério sobre trabalhar conosco. Eles nos 
garantiram que realmente estavam interessados. 

Entáo eu pedi outra reuniáo com Keith e disse que eu estava disposto a sair da GE 
para trabalhar com eles em período integral nos próximos meses e explorar outras 
oportunidades de startup. Essa oportunidade se materializou porque eu consegui 
convencé-los de que eu estava disposto a colocar minha própria pele na jogada, uma 
vez que eu havia deixado a GE sem um caminho claro e seguro diante de mim. 

Durante os próximos 12 meses, todo dia nós nos encontrávamos com equipes 
diferentes, selecionando suas ideias, e eu reparei em um novo padráo no conjunto 
de questóes que perguntávamos a cada empresa. 

Eu compilei essa lista e estou compartilhando as questöes com vocé, no caso 
de vocé precisar arrecadar dinheiro de investidores de risco no futuro; veja http: 
//www.greaterlouisville.com/EnterpriseCORP/Forms/BusinessAssessment/. 

As habilidades que eu adquiri durante aquele ano na bCatalyst me levaram ao 
meu emprego atual, como diretor administrativo da Enterprise Corp. Nos ultimos 
sete anos, eu trabalhei com mais de 100 empresas e ajudei a arrecadar um fundo de 
mais de 75 milhóes de dólares. Essa tem sido uma experiéncia extremamente satis- 
fatória, que nao teria sido possível se eu nao tivesse tomado a iniciativa e sido aven- 
tureiro em tentar coisas novas. Os vários zig-zags ao longo do caminho foram parte 
integral do processo. Minha esperanga é de que vocé, leitor, use minha história para 
se inspirar a encontrar seu próprio caminho, aquele que vai usar suas habilidades ao 
máximo. 

Vik Chadha é o diretor administrativo da Enterprise Corp. 


Faca algo 


1) Escolha uma tarefa que vocé normalmente faz de forma repetitiva e escreva um 
gerador de código para ela. Náo se preocupe com reusabilidade. Apenas garanta 
que seu gerador economize tempo. 


Pense em uma maneira de aumentar o nivel de abstragäo do que vocé está ge- 
rando. 


2) Pesquise por model-driven architecture (MDA — Arquitetura orientada a mo- 
delo). Experimente algumas das ferramentas disponíveis. Procure algum lugar 
do seu trabalho no qual aplicar alguns conceitos de MDA, ou talvez o grupo com- 
pleto de ferramentas. Pense em aplicar os conceitos de MDA apenas com as fer- 
ramentas que vocé utiliza todo dia. 
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Agora mesmo 


Imagine que vocé está em uma corrida com um prémio de $100000. Vence a pri- 
meira equipe que criar um software para implementar uma aplicação de contas a 
receber. Vocé e sua equipe se inscreveram para competir. O concurso vai acontecer 
em uma semana. Para ganhar, seu código deve ser completamente testado e imple- 
mentar um conjunto mínimo de funcionalidades. Vocé comega sábado de manhä, 
e tem até segunda-feira de manhã para completar sua aplicação. A primeira equipe 
que concluir antes de segunda de manhã ganha a corrida. Se nenhum time terminar 
antes disso, o que tiver mais funcionalidades implementadas vence. 

Você folheia os requisitos das funções da aplicação. Olhando para a lista de fun- 
cionalidades, você percebe que o sistema é semelhante em tamanho e escopo a vários 
sistemas com que você trabalhou no passado. Enquanto o objetivo acordado em sua 
equipe é terminar no meio do dia de domingo, por um momento você começa a se 
questionar. Como é que uma aplicação de escopo similar aquelas nas quais pas- 
samos semanas trabalhando no escritório vai ser concluída em um único final de 
semana? 
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Mas com o começo da competição você começa a codificar e percebe que sua 
equipe vai ser capaz de alcançar o objetivo. A time está em um movimento coletivo, 
produzindo recurso depois de recurso, consertando erros, tomando decisões em fra- 
ções de segundo, e concluindo as funcionalidades. Você se sente bem. Em revisões 
de projeto e reuniões de status lá na sua empresa, você sonhava pegar uma pequena 
equipe, tirar daquele ambiente burocrático para se dedicar à criação de uma nova 
aplicação em tempo recorde. 

Muitos de nós têm esse sonho. Sabemos que nossos processos nos atrasam. Não 
apenas isso, mas sabemos que a velocidade de nossos ambientes nos faz ir mais de- 
vagar. 


O que podemos fazer? Agora mesmo? 


A lei de Parkinson afirma que “O trabalho se expande até preencher o tempo 
disponível em sua completude” O lado triste é que, mesmo quando você não quer 
que seja desse jeito, você pode cair na armadilha, especialmente quando existem 
tarefas que você não quer fazer. 

No caso de uma corrida para implementar um sistema em um final de semana, 
você não tem tempo de deixar as tarefas de lado, então você não o faz. Você não pode 
atrasar uma decisão, então você não o faz. Você não pode evitar trabalho chato, e 
você sabe que deve fazê-lo tão rápido que nada pode ser tão chato. 

A lei de Parkinson é uma observação empírica — e não um mandato humano 
inescapável. Um senso de urgência, mesmo manufaturado, é suficiente para facil- 
mente dobrar ou triplicar sua produtividade. Tente isso, e você verá. Você pode fazer 
mais rápido. Você pode fazer agora. Você pode torná-lo pronto em vez de conversar 
sobre torná-lo pronto. 

Se você tratar seus projetos como uma corrida, você chegará ao final muito mais 
rápido do que se você tratá-los como uma cela de prisão. Crie movimento. Seja 
aquele que empurra. Não fique confortável demais. 


Sempre seja aquele que pergunta “Mas o que pode ser feito agora mesmo?” 
Faça algo 


1) Olhe para sua escrivaninha. Examine as tarefas que estão lá por um longo tempo, 
os projetos que estão começando a tomar forma, ou aqueles em que você está um 
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pouco travado — talvez por questóes burocráticas, talvez travados por conta de 
algum análise. 


Encontre um que vocé poderia fazer nas horas livres do seu trabalho normal, 
quando vocé estaria provavelmente navegando pela internet, checando e-mails 
ou tendo um almogo por mais de uma hora. Transforme um projeto de meses 
em uma tarefa de menos de uma semana. 
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CAPÍTULO 20 


Leitor de mentes 


Eu trabalhava com um rapaz chamado Rao. Ele vinha de um estado do sul da Índia 
chamado Andhra Pradesh, mas estava alocado nos Estados Unidos e trabalhava com 
a gente. Ele era o tipo de pessoa que podia codificar qualquer coisa que vocé pedisse. 
Se vocé precisasse de programagäo de sistema de baixo nivel, ele era a pessoa a quem 
pedir. Se você precisasse de programação de aplicações de alto nivel, ele poderia 
fazer praticamente tudo que você pedisse. 

Entretanto, o que tornou Rao verdadeiramente diferenciado foi o que ele fez an- 
tes de você pedir. Ele tinha essa misteriosa habilidade de prever o que você estava 
prestes a pedir, e o fazia mesmo antes de você pensar nisso. Era como mágica. Acre- 
dito que eu até o acusei de aplicar truques em mim, em certo ponto, mas não há como 
ter sido truque. Eu diria “Rao, estive pensando sobre mudar a forma como estamos 
encapsulando o controlador no framework da nossa aplicação. Se nós mudássemos 
apenas um pouco, ele poderia ser usada além da web. O que você acha?” 

“Eu fiz isso no começo dessa semana”, ele diria. “Dá uma olhada lá no controle 
de versão” Isso constantemente acontecia com Rao. Era tão frequente que a única 
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forma de isso ter sido uma coincidéncia era se Rao estivesse literalmente fazendo 
qualquer coisa imaginável com o software que a equipe mantinha. 

Naquela época, eu liderava a equipe de arquitetura de aplicações da minha em- 
presa. Entre outras coisas, nós construíamos e mantínhamos frameworks para uso 
nas aplicações da empresa. Meus colegas de equipe passavam muito tempo conver- 
sando sobre como queríamos ver a área de desenvolvimento de software na empresa 
melhorar. Também conversávamos bastante sobre o papel dos componentes de nossa 
infraestrutura básica nessas melhorias. 

É aí que os truques de mágica de Rao entravam. Ele náo falava muito nessas 
conversas, mas ele náo era nem um pouco desengajado. Ele ouvia com atengáo. E, 
entregando seu segredo como nenhum mágico faria, ele depois me contou que o 
truque era que ele estava apenas fazendo coisas que eu já havia dito que queria. Eu 
já o havia dito de maneira táo sutil que nem eu percebia o que dissera. 

A gente podia estar esperando o café ficar pronto e eu dizia sobre como seria 
ótimo ter alguma nova flexibilidade no nosso código. Se eu o dissesse com frequén- 
cia ou convicção suficientes, mesmo sem colocá-lo na lista de afazeres da equipe, Rao 
iria preencher as lacunas entre “trabalho real” analisando a viabilidade de implemen- 
tar um daquelas coisas. Se fosse fácil (e barato) de implementar, ele iria eliminar a 
tarefa colocando-a em funcionamento. 


O truque da leitura de mente, se feito certo, faz as pessoas dependerem de vocé. 


Leitura de mente náo apenas se aplica aos seus chefes, mas também aos seus 
clientes. Se eles estáo dando as dicas certas, vocé pode ser capaz de acrescentar fun- 
cionalidades que eles ou váo pedir ou teriam pedido se tivessem percebido que elas 
eram possiveis. Se vocé sempre faz o que seus clientes pedem quando eles pedem, 
vocé os satisfará. Todavia, se vocé fizer mais do que eles pedem, ou se vocé já tiver 
feito antes de eles pedirem, isso irá encantá-los, isto é, ao menos que sua habilidade 
de ler mentes seja defeituosa. 

Esse truque de leitura de mente náo é inteiramente seguro. É uma corda bamba 
sobre a qual vocé quer evitar andar, ao menos que haja uma rede segura embaixo. 
Os maiores riscos (alguns atenuados) sáo os seguintes: 


e Você gasta o dinheiro da empresa fazendo trabalho que não foi pedido. E se 
você estiver errado? Comece pequeno. Só faça suposições do que pode ser 
encaixado nas frestas do seu trabalho normal, de modo que o impacto seja 
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pequeno ou nulo. Se vocé está táo disposto, dedique-se a esse trabalho extra 
no seu tempo livre. 


e Toda vez que você adiciona código em um sistema, você corre o grande risco 
de torná-lo menos resistente a mudangas. Evite trabalho de leitura de mente 
que pode forcar o sistema a um determinado caminho arquitetónico ou limi- 
tar de alguma forma o que ele pode fazer. Quando o impacto da mudanca 
é grande o suficiente, é necessária uma decisáo de negócio. Raramente sáo 
apenas os desenvolvedores que precisam opinar em tal decisáo. 


e Você pode decidir mudar uma funcionalidade que seus clientes pediram, de 
uma maneira que, inesperadamente, a torne menos funcional ou desejável 
para o cliente. Esteja atento ao adivinhar quando se trata especificamente de 


interface de usuário. 


Gerenciar pessoas e projetos é um trabalho desafiador. Pessoas que podem man- 
ter um projeto andando na direção certa, sem que seja dada muita orientação, pos- 
suem alto valor e sáo reconhecidas por seus sobrecarregados gerentes e clientes. O 
truque de leitura de mente, se feito certo, faz as pessoas dependerem de vocé - uma 
excelente receita para uma carreira cuja direção você pode controlar. É uma habili- 
dade que vale ser explorada e desenvolvida. 


Faça algo 


1) Um revisor do início deste livro, Karl Brophey, sugere que, em seu novo projeto 
ou para um sistema que você mantém, você comece a tomar notas sobre o que 
você acha que os usuários e chefes vão pedir. Seja criativo. Tente ver o sistema a 
partir do ponto de vista deles. Depois de ter uma lista das funcionalidades não 
tão óbvias que podem aparecer, pense sobre como você poderia implementá-las 
de forma mais eficiente. Pense sobre casos limites que seus clientes podem não 


ter em mente imediatamente. 


Conforme você explora as solicitações de melhoria, acompanhe sua taxa de 
acerto. Quantas de suas suposições tornaram-se funcionalidades que realmente 
foram requisitadas? Quando suas suposições vieram à tona, você foi capaz de 
usar as ideias que vieram em sua sessão de brainstorm? 
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CAPÍTULO 21 


Exito diário 


Todos nós gostamos de pensar, pela virtude de nosso conhecimento e por sermos 
bons em software, que naturalmente vamos dominar um assunto e virar referéncia. 
Para a minoria sortuda (e eu realmente pretendo usar a palavra sorte aqui), uma 
estratégia como essa vai funcionar. 

Porém, todos nós podemos tirar benefícios a partir do agendamento e do acom- 
panhamento do nosso desempenho. O senso comum afirma que se excedermos as 
expectativas dos nossos chefes estaremos na lista A. Dado que exceder as expecta- 
tivas é uma meta digna, surpreendentemente poucos de nós tém mecanismos para 
acompanhar como e quando excederam as expectativas de seus patróes. 

Assim como a maioria das tarefas dignas de serem feitas, tornar-se alguém des- 
tacado é mais provável com algum trabalho específico e intencional. Quando foi a 
última vez que vocé foi além do chamado de dever? Seu chefe soube disso? Como 
vocé pode melhorar a visibilidade desse comportamento? 


Tenha uma realizagäo para relatar todo dia. 
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James McMurry, um colega de trabalho que também é um grande amigo 
(http://semanticnoise.com) , contou-me no inicio de nossas carreiras sobre um sis- 
tema que ele inventou para se certificar de que estava fazendo um bom trabalho. 
Impressionou-me sendo extremamente perspicaz, dada sua experiéncia (talvez seja 
uma dica dada por seus pais), e eu o uso até hoje. Sem avisar seu chefe, ele come- 
¿ou a acompanhar seus êxitos diários. Seu objetivo era, cada dia, ter algum tipo de 
conquista marcante para relatar a seu chefe - alguma ideia em que ele pensou ou 
implementou, que tornaria seu departamento melhor. 

Simplesmente estabelecendo um objetivo (diário, semanal, ou quando vocé for 
capaz) e acompanhando seus éxitos é possível mudar seu comportamento radical- 
mente. Quando você começa a procurar por conquistas marcantes, você natural- 
mente entra no processo de avaliar e priorizar suas próprias atividades, baseado no 
valor de negócio daquilo em que você pretende trabalhar. 


Segunda: cometan Ala 47 


Quanta Tran Rls Pr um 
OM d 


Qing: Decora, A | 
[4 


XX le 


Tien AN ps dy 
Proge 


Figura 21.1: Uma semana de êxitos 


Acompanhar seus êxitos com uma frequência razoavelmente alta vai assegurar 
que você não fique travado: se você deve alcançar um êxito por dia, não pode passar 
duas semanas elaborando a tarefa perfeita. O tipo de pensamento e trabalho torna- 
se um hábito, em vez de uma produção maior. E, assim como um desenvolvedor 
viciado na barra verde de uma suíte de teste de unidade, você começa a ficar irritado 
se não alcançou o êxito do dia. Não é preciso se preocupar muito em acompanhar 
seu progresso, porque agir nesse nível parece mais com um tique nervoso do que um 
conjunto de tarefas que precisam ser planejadas em um Microsoft Project. 
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Faca algo 


1) Separe meia hora de sua agenda, e sente-se com um papel e lápis em um lugar 
tranquilo onde vocé náo será interrompido. Pense sobre as pequenas picuinhas 
dos problemas diários de sua equipe. Escreva-os. Quais sáo as tarefas irritantes 
que gastam alguns minutos do tempo da equipe todo dia, mas que ninguém tem 
tempo ou energia de resolver? 


Em que lugar do seu atual projeto vocé está fazendo algo manualmente que podia 
ser automatizado? Escreva-o. E quanto a seu processo de build ou deploy? Há 
alguma coisa que vocé poderia limpar? Como vocé poderia reduzir falhas em 
seu build? Escreva todas essas ideias. 


Dé a si mesmo sólidos vinte minutos para isso. Escreva todas suas ideias — boas 
ou ruins. Náo se permita terminar antes dos vinte minutos. Depois de ter feito 
uma lista, em um novo papel, escreva seus cinco itens favoritos (mais irritantes). 
Na semana seguinte, na segunda-feira, pegue o primeiro item da lista, e faça algo 
a respeito dele. Na terça-feira, pegue o segundo item. Na quarta-feira, o terceiro, 


e assim por diante. 
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CAPÍTULO 22 


Lembre-se de para quem vocé 
trabalha 


É muito fácil dizer “Certifique-se de que seus objetivos e seu trabalho estejam ali- 
nhados com os objetivos de sua empresa”. É muito fácil dizer; mas é muito difícil 
fazer, especialmente quando vocé é um programador enterrado sob tantas cama- 
das organizacionais. No início da minha carreira, eu trabalhava para uma grande 
empresa de entrega de pacotes, em uma equipe de arquitetura de desenvolvimento 
de software apoiando os sistemas definidos pela empresa. Ela estava táo entravada 
com hierarquia, que eu nunca vi nada no meu trabalho diário que chegasse perto de 
entrega de pacotes. Lembro-me de minha equipe participando das reunióes trimes- 
trais, sentindo-se completamente deslocados e alienados. “Qual é a conquista que 
estamos comemorando? O que toda essa métrica significa?” 

De fato, nesse ponto de minha carreira, eu estava mais interessado em construir 
sistemas elegantes e hackear softwares open sources, do que mergulhar nas profun- 
dezas de um negócio de entrega de pacotes. (OK, eu admito - eu ainda sou mais 
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interessado naquelas coisas). Mas se eu realmente quisesse alinhar meus objetivos 
com os da empresa, eu náo tenho certeza se eu saberia por onde comegar. 

Entáo está certo dizer que precisamos alinhar nosso trabalho com as metas da 
empresa - para tentarmos assegurar que estamos impactando o ponto de partida 
de tudo aquilo. Contudo, que a verdade seja dita, muitos de nós simplesmente náo 
enxerga como fazer isso do lugar onde estáo. Náo podemos ver a floresta por causa 
das árvores. 

Talvez isso náo seja nossa culpa. Talvez estejamos cobrando muito de nós mes- 
mos. Talvez a ideia de tentar impactar diretamente a empresa seja equivalente a ten- 
tar ferver o oceano. Portanto, precisamos ter uma visáo mais compartimentada, di- 
vidindo o negócio em pogas fervíveis. 

A poça mais óbvia com a qual começar é sua própria equipe. É provavelmente pe- 
quena e suficientemente focada, de modo que você pode conceitualmente se envol- 
ver em torno dela. Você muito provavelmente entende os problemas que sua equipe 
enfrenta. Você sabe no que ela está focada em melhorar, seja na produtividade, no 
rendimento, redução de erro, ou qualquer outra coisa. Se você não tem certeza, há 
um lugar óbvio para se descobrir: seu chefe. 

Em última análise, em um ambiente bem estruturado, os objetivos de seu chefe 
são os mesmos de sua equipe. Resolva o problema de seu chefe e terá resolvido um 
problema para a equipe. Adicionalmente, se seu chefe possui a mesma abordagem 
que você, os problemas que você está resolvendo para ele, na verdade, são os pro- 
blemas do chefe dele. E assim por diante, até que isso chega no nível mais alto da 
empresa - o CEO, os acionistas, ou até mesmo os consumidores. 

Fazendo sua pequena parte, você estará contribuindo para a realização das metas 
de sua empresa. Isso pode dar-lhe um senso de propósito. Isso dá significado ao seu 
trabalho. 

Alguns podem resistir a essa estratégia. “Eu não vou fazer esse serviço para ele”, 
ou, “Ela vai levar crédito pelo meu trabalho!” 

Bom, sim. Mais ou menos. É assim que funciona. O papel de um bom chefe 
não é, como Lister e DeMarco dizem em Peopleware [2], “ser um jogador reserva do 
time” sabendo fazer todo o trabalho da equipe. O papel de um bom chefe é colocar 
prioridades para a equipe, certificar-se de que ela tem o que precisa para realizar o 
trabalho, e fazer o que for preciso para manter a equipe motivada e produtiva, por 
fim, fazer o que deve ser feito. Um trabalho bem feito pela equipe é um trabalho bem 
feito pelo chefe. 


O sucesso de seu chefe é o seu sucesso. 
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Se a fungäo do chefe é saber e estabelecer prioridades, mas näo pessoalmente 
realizar o trabalho, logo, sua função é fazer todo o trabalho. Você não está fazendo 
o serviço de seu gerente. Você está fazendo seu serviço. 

Se você realmente está preocupado com quem recebe os créditos, lembre-se que 
é seu chefe que detém as chaves de sua carreira (em sua atual empresa, pelo menos). 
Na maior parte das empresas, é o chefe direto quem influencia a avaliação das per- 
formances, ações salariais, bônus e promoções. Portanto, o crédito que você busca 
fica depositado com seu gerente. 

Lembre-se de para quem você trabalha. Você não vai somente se alinhar com as 
necessidades do negócio, mas alinhar o negócio com suas necessidades. Se você vai 
dominar a execução de sua função, isso vai assegurá-lo de executar as coisas certas. 


Faça algo 


1) Agende uma reunião com seu chefe. Esse compromisso é para você entender as 
metas de seu chefe para a equipe para o próximo mês, trimestre, e ano. Pergunte 
como você pode fazer a diferença. Após a reunião, examine como seu trabalho 
diário se alinha aos objetivos de sua equipe. Faça com que eles sejam um filtro de 
tudo o que você faz. Priorize seu trabalho de acordo com esses objetivos. 
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CAPÍTULO 23 


Esteja onde vocé está 


Como chefe, posso dizer que a coisa mais frustrante é lidar com um funcionário que 
está sempre almejando o próximo degrau da escada. Vocé conhece o tipo: vocé náo 
consegue sentar com ele no almogo sem que ele traga o assunto de quem recebeu 
qual promogáo. Ele sempre tem algum tipo de fofoca do escritório para espalhar, e 
ele parece se apegar a política corporativa como se fosse o enredo de uma novela na 
qual ele seja viciado. Ele reclama sobre a incompeténcia da geréncia, e com muito 
desgosto completa suas tarefas, sabendo muito bem que ele podia exercer a função 
de chefe melhor do que eles. Eles só são incompetentes para entender seu potencial. 

Ele pensa que muitas tarefas estão abaixo dele. Ele as evita quando possível e 
as faz a contragosto (e lentamente), quando não. Ele escolhe trabalhos que acha, 
mesmo subconscientemente, que estão de acordo com seu nível e que podem levá- 
lo à próxima promoção. 


Seja ambicioso, mas não demonstre. 


Casa do Código 





A coisa triste sobre esse cara é que, pelo fato de ele estar vivendo em seu próximo 
emprego, ele geralmente está fazendo um trabalho medíocre na sua fungäo atual. É 
como aparar a grama para mim. Eu detesto aparar a grama. Isso me dá coceiras e 
me faz suar. Pior de tudo, isso faz com que eu náo faga algo que eu preferia estar 
fazendo. Vocé pode contratar pessoas para apararem sua grama. Eu fui uma dessas 
pessoas. Isso foi há muito tempo, e agora eu progredi. Entáo, quando eu preciso 
aparar a grama, o que eu faço? Eu me apresso. Faço um serviço desleixado. Passo o 
tempo todo pensando em como acabar logo com isso para que eu possa me dedicar 
às coisas que eu preferia fazer. Resumindo, eu faço um péssimo serviço ao aparar a 
grama. 

Ainda bem que, no meu exemplo de aparar a grama, ninguém está me obser- 
vando e me avaliando (apesar de que minha esposa ficou tão irritada que eu não sou 
mais o responsável pela grama na nossa casa). O problema é meu se a grama não 
está ótima quando concluí o trabalho. Ninguém está me segurando para ser “apenas 
um cortador de grama” por causa da minha performance no jardim. No caso de um 
emprego de TI, o mesmo comportamento pode provocar uma catástrofe em uma 
carreira. Voltando ao nosso amigo dos parágrafos anteriores, como você acha que 
a administração o verá? Eles verão que estavam errados ao negligenciar seu talento 
brilhante e decidirão promovê-lo? Eles darão grandes aumentos para fazê-lo feliz? 

Claro que não. Ele é um funcionário ridículo com uma atitude ruim. E daí se 
ele tem alto potencial! Por enquanto, ele não o está mostrando. A empresa não faz 
dinheiro por causa de potencial. Acionistas não mantêm seus investimentos se o 
potencial não é efetivado. Além disso, sua atitude faz seus chefes quererem parar de 
investir nele. 

Então, esse é o ponto de vista de um gerente. Agora, claro, eu não estou com- 
pletamente isento de culpa aqui. Eu fui essa pessoa por algum tempo. Também não 
é muito bom desse lado da rua. Você passa todo seu tempo desejando algo. Desejo 
é o oposto de satisfação. Você acorda de manhã e tem que ir para “aquela droga de 
emprego” onde ninguém entende seu potencial. Com ressentimento, você labuta em 
seu serviço, repassando estratégias para subir de cargo. Você fantasia sobre o que 
você faria na última situação em que seu chefe errou as coisas - como você lidaria 
com isso diferentemente. Você adia viver enquanto você está trabalhando até que 
você possa fazer do seu jeito, na posição que você merece. 

Aqui está um segredo: essa sensação nunca vai passar. Se e quando você final- 
mente conseguir a grande promoção com a qual você tem sonhado, você rapida- 
mente vai se cansar e perceber que não é este trabalho que você queria - é o pró- 
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ximo. O ciclo começa de novo. Eu ainda não alcancei o topo, mas eu tenho a forte 
intuicäo de que se houvesse tal posigäo, e eu a alcancasse, eu olharia para cima e 
perceberia que estava perseguindo um fantasma. Que frustrante desperdicio de vida 
profissional. 

Mas nós não deveríamos ter ambições? Haveria uma Microsoft ou uma General 
Electric se grandes empreendedores não tivessem ambicionado e tido metas? 

Claro que deveríamos. Eu não estou defendendo uma visão apática. É bom ter 
objetivos, e é bom querer ter sucesso. Mas pense no cara negativo e ressentido que 
eu descrevi no começo desse capítulo. Você acha que ele vai ser a pessoa que tem su- 
cesso? Parece retrógrado, mas focar-se no presente vai levá-lo mais longe em direção 
aos seus objetivos, do que manter sua mente focada no objetivo em si. 

Você vai descobrir que isso é muito pragmático. Focar no presente vai permitir- 
lhe aproveitar as pequenas vitórias do dia a dia de trabalho: a sensação de trabalho 
bem feito, a sensação de ser considerado um expert em um problema crítico de ne- 
gócio, a sensação de ser um membro integral de uma equipe bem sucedida. 

Isso é o que você vai perder se estiver sempre com a cabeça nas nuvens. Você es- 
tará sempre esperando o grandioso, enquanto ignora as pequenas coisas que acon- 
tecem todo dia, que fazem valer a pena aparecer em seu serviço. 

Não apenas você vai se sentir bem, mas aqueles ao seu redor também vão. Seus 
colegas de trabalho, chefes e clientes vão senti-lo. Isso vai transparecer no seu tra- 
balho. Por mais contraintuitivo que pareça, deixar de lado seu desejo de ter sucesso 
resultará em uma aprimorada habilidade de ser bem sucedido. 

Você é próximo aos seus clientes. Você é próximo aos líderes com poder de de- 
cisão que vão modelar sua carreira a curto prazo e, possivelmente, a longo prazo. 
Desenvolvedores na Índia ou nas Filipinas não possuem essa vantagem, mas você 


tem. Portanto, esteja onde você está. 
Faça algo 


1) Coloque as metas de sua carreira de lado por uma semana. Escreva seus obje- 
tivos para seu emprego atual. Em vez de pensar sobre aonde você quer ir em 
seguida, pense sobre o que você quer ter alcançado quando você terminar o tra- 
balho no qual está agora. O que você pode ter produzido nesse emprego que terá 
sido ótimo? Crie um plano que seja ambos estratégico e tático. Passe a semana 
implementando essas táticas em apoio às metas a longo prazo de “terminar” esse 
trabalho. 
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Durante almoços e intervalos com seus colegas, foque a conversa nesses objetivos. 
Quanto tempo vai passar até que vocé conquiste tudo o que sente que precisa 
em sua fungäo atual? Como vocé saberä que terá concluido? Planeje a próxima 
semana e repita. 
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CAPÍTULO 24 


Quäo bom eu posso fazer um 
trabalho hoje? 


É recompensador realizar um bom trabalho e ser reconhecido. Embora a maioria de 
nós saiba disso intuitivamente, somos extremamente seletivos sobre onde e quando 
realmente vamos além do nosso trabalho para nos sobressairmos. Nós podemos 
nos dedicar cegamente ao design do Novo Grande Projeto do departamento de mar- 
keting, ou nós rapidamente mergulhamos em um problema para salvar o dia em 
alguma grande catástrofe, porque nossos cérebros estáo programados para entender 
tais momentos como oportunidades de exibir nosso notório material. Podemos até 
mesmo fazer o trabalho no meio da noite, com um nível de foco de detalhe que nor- 
malmente nos levaria as lagrimas. Uma situação terrível pode frequentemente fazer 
surgir o melhor em nós. 

Eu já deixei essa sensação inebriante de exaltação manter-me acordado e efeti- 
vamente trabalhando em algumas das mais cansativas falhas de sistema e prazos não 
cumpridos. Por que é que, quando não há grandes pressões, nós geralmente não so- 
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mos capazes desse tipo de comportamento de altruísmo e de frenesi ultraprodutivo? 
Quäo bem nós atuariamos se pudéssemos tratar as tarefas mais desinteressantes e 
chatas com o mesmo desejo fervoroso de fazé-las direito? 


Quáo mais divertido vocé pode tornar seu trabalho? 


A última questáo fica melhor se a reescrevermos. Quáo mais divertido seria seu 
trabalho se vocé pudesse tratar as tarefas mais chatas com o mesmo desejo fervo- 
roso de fazé-las direito? Quando temos mais diversáo, fazemos um melhor trabalho. 
Entáo, quando náo temos interesse em uma tarefa, ficamos entediados e, como re- 
sultado, nosso trabalho também sofre. 

Como transformar um trabalho entediante em um mais divertido? A resposta a 
essa pergunta pode ser mais aparente se vocé inverté-la. Por que o trabalho entedi- 
ante é entediante? Por que ele ainda näo é divertido? Qual a diferenga entre trabalho 
que vocé aprecia e trabalho que vocé abomina? 

Para muitos de nós, técnicos, o trabalho entediante é assim por dois motivos 
primários. O trabalho que amamos nos permite flexionar nossos músculos criativos. 
Desenvolvimento de software é um ato criativo, e muitos de nós somos atraídos para 
isso por essa razáo. O trabalho que náo amamos é raramente o que consideramos 
de natureza criativa. Pense sobre isso por um momento. Pense sobre o que está 
em sua lista de tarefas para a próxima semana. As tarefas que vocé adoraria pular 
provavelmente náo dáo muito espago para a imaginacáo. Elas sáo apenas tarefas a 
fazer, que vocé gostaria de poder delegar a outra pessoa. 

A segunda razáo pela qual tarefas chatas sáo chatas, e relacionada á primeira, 
é que as tarefas chatas náo sáo desafiadoras. Nós amamos mergulhar em um pro- 
blema difícil e resolver coisas que outros náo conseguiram. É o mesmo sentimento 
que motiva membros de nossa espécie a recreativamente arriscar suas vidas esca- 
lando montanhas e saltando de bungee jump. Amamos fazer coisas para provar que 
somos capazes. Tarefas chatas normalmente náo estimulam o cérebro. Fazé-las é táo 
desafiador quanto colocar o lixo para fora de casa. 

Entáo como é possível ainda usarmos nossa criatividade e desafiar a nós mes- 
mos enquanto tendemos ás sobras mundanas do nosso dia de trabalho (que prova- 
velmente tomam mais de 80% do tempo da maioria de nós)? 

E se você tentasse fazer as coisas chatas perfeitamente? Digamos que, por exem- 
plo, vocé odeia teste de unidade. Vocé ama programar, mas fica entediado em ter de 
escrever código de teste automatizado. E se vocé se esforcar para fazer seus testes 
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perfeitos? Como isso mudaria seu comportamento? O que perfeito significa em re- 
lacáo a teste de unidade? Provavelmente terá algo a ver com cobertura de teste. Isso 
significaria que vocé testou 100% da funcionalidade do seu código. Testes de unidade 
perfeitos também são limpos e de fácil manutenção, e não dependem de muitos fa- 
tores externos que podem ser difíceis de replicar em outro computador. Eles deviam 
ser executáveis diretamente depois de um checkout no controle de versão. E, é claro, 
todos os testes deviam passar. 

Isso está começando a parecer difícil; uma cobertura de teste de 100% é quase 
impossível. E o negócio de dissociação de testes de modo que eles possam rodar sem 
dependências externas apresenta vários desafios. Aliás, você provavelmente terá que 
modificar seu código para tornar isso possível. Mas, se você pudesse fazê-lo, os testes 
seriam incríveis. 

Eu não sei quanto a você, mas isso me parece até divertido. De fato, você pode 
aplicar o mesmo pensamento para a maioria das tarefas que cruzam seu caminho. 
Tente isso amanhã. 

Olhe para seu trabalho e pergunte a si mesmo: “Quão bom eu posso fazer isso 
hoje?” Você descobrirá que você gostará mais de seu emprego e ele gostará de você. 


Faça algo 


1) Torne isso visível — Transforme aquelas tarefas chatas em uma competição com 
seus colegas de trabalho. Veja quem pode fazê-las melhor. Não gosta de escrever 
testes de unidade? Imprima o número de asserts dos seus testes todo dia, e o 
pendure em sua parede. Mantenha uma tabela de pontos para a equipe inteira. 
Compita pelo direito de se gabar (ou mesmo por prêmios). Ao final, faça com que 
o vencedor ganhe um prêmio, por exemplo, ter os testes feitos por outra pessoa 
da equipe por uma semana. 
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CAPÍTULO 25 


Quanto vocé vale? 


Vocé já parou para analisar exatamente quanto vocé custa para a empresa na qual 
trabalha? Quero dizer, vocé sabe o seu salário. Esta parte é fácil. Mas e quanto a 
benefícios, despesas de gerenciamento, e todas as outras coisas que náo necessaria- 
mente aparecem em seu holerite? 

É fácil simplesmente querer mais. Infelizmente, isso parece ser uma tendéncia 
básica humana, de fato. Vocé recebe um aumento e isso faz-lhe sentir bem por um 
tempo, mas a partir de então você começa a pensar no próximo. “Se eu pudesse fazer 
apenas 10% mais, eu poderia comprar aquele novo..”. Todos nós fizemos isso. Em 
algum momento, o número verdadeiro se torna abstrato. Náo se trata mais de 10% a 
mais por més. Trata-se de fazer qualquer que seja o número atual subir mais. Se náo 
recebemos um aumento de salário satisfatório em um ano, tornamo-nos insatisfeitos 
com nosso trabalho e nossa empresa. “Por que eles náo gostam de mim?” 

Quanto vocé realmente custa? Como eu já mencionei, é obviamente mais do que 
seu salário básico. Por uma questáo de discussáo, vamos fazer a estimativa com duas 
vezes seu salário. Entáo, se vocé ganha 5 mil por més, a empresa realmente gasta em 
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torno de 10 mil mantendo vocé empregado. 

Isso foi fácil. Agora a parte difícil: quanto valor vocé produziu no ano passado? 
Qual foi seu impacto positivo no resultado final da empresa? Já sabemos que vocé 
custa á empresa (em nosso cenário imaginário) aproximadamente 10 mil por més. 
O que vocé deu em troca? Quanto dinheiro vocé fez a empresa economizar? Quanto 
mais contribuiu na receita dela? 

Esse número é maior do que o dobro do seu salário? 

É um exercício complicado de fazer, porque geralmente é difícil relatar cada as- 
pecto de seu trabalho no resultado final da empresa. Pode até parecer uma pergunta 
sem sentido para você. “Como eu vou saber? Eu sou apenas um programador!” 
Este, é claro, é o ponto. Vocé trabalha para um negócio e, ao menos que vocé for- 
neca algum tipo de valor real, vocé é um desperdício de dinheiro. É fácil cair na 
armadilha de pensar que aumentos de salário sáo um direito. Analogamente, uma 
empresa tem o direito de cobrar mais por seus produtos todo ano. Mas, por sua vez, 
os consumidores tém o direito de náo comprar aquele produto se o preco náo os 
atrair. 

Agora que você começou a pensar sobre quanto você custa versus quanto você 
entrega, quanto vocé acha que vocé precisa entregar para ser considerado um inves- 
timento de valor a empresa? Conversamos sobre o cenärio do dobro de seu salário, 
mas isso é o suficiente? Se vocé entregar valor totalizando o dobro de seu salário, a 
empresa ficou no zero a zero. Este é um bom jeito de gastar dinheiro? 

Como um ponto de referéncia, pense sobre a taxa de juros de uma conta pou- 
pança de um cliente comum. Não é lá grande coisa, certo? Ainda assim, é definiti- 
vamente melhor que zero. Dadas as opções, você colocaria as economias de um ano 
em uma conta poupança que produz 0% ou 3%? Entregar apenas o seu salario como 
valor não é interessante do ponto de vista de uma empresa, assim como uma conta 
poupança de 0% é para você. Eles se comprometeram a 10 mil por mês, e você não 
está nem mesmo entregando valor suficiente para acompanhar a taxa de inflação da 
economia. Um empate neste caso é, na verdade, ainda uma perda. 

Lembro de quando comecei a pensar dessa maneira. Isso me deixou paranoico 
no começo. Um més se passava, e eu ficava pensando: “O que eu entreguei este mês?” 
Então, eu comecei a ficar tão granular como as semanas e dias. “Fui valioso hoje?” 


Pergunte-se: “Fui valioso hoje?” 


Você pode tornar isso concreto. Apenas quanto valor você adiciona? Converse 
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com seu chefe sobre a melhor forma de quantificá-lo. O puro fato de vocé querer 
quantificá-lo será levado como uma coisa boa. Como vocé poderia criativamente 
economizar o dinheiro da empresa? Como vocé poderia tornar sua equipe de de- 
senvolvimento mais eficiente? Ou e quanto aos usuários finais de seu software? Vocé 
se surpreenderá com quantas oportunidades você pode identificar se começar a fazer 
essas perguntas. Agora, comece a implementar algumas delas. Mantenha essa ima- 
gem em sua cabeça: o dobro do meu salário. Não pare até que você tenha superado 
aquele número para o ano. 


Faça algo 


1) Quando empresas fazem investimentos, eles tentam se assegurar que estão 
usando seu dinheiro da melhor maneira possível. Simplesmente calcular o re- 
torno de um investimento (eu coloco 100 e obtenho 120) não é o suficiente para 
tomar uma decisão inteligente. Dentre outros fatores, empresas têm que conside- 
rar inflação, custo de oportunidade e riscos. Especificamente não-intuitivo para 
aqueles que não frequentaram faculdade de economia ou administração, está o 
conceito de valor do dinheiro no tempo. Com o risco de estar simplificando de- 
mais, é algo assim: um dólar hoje vale mais que um dólar no ano que vem, porque 
um dólar hoje pode ser usado para gerar mais dólares. 


A maioria das empresas estabelece uma barra da taxa de retorno, abaixo da qual 
um investimento não será feito. Investimentos devem render uma porcentagem 
acordada em um período de tempo acordado, ou eles não são feitos. Este número 
é chamado de taxa mínima. 


Descubra qual a taxa mínima de sua empresa, e aplique isso a seu salário. Você é 
um bom investimento? 
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CAPÍTULO 26 


Uma pedrinha em um balde dagua 


O que aconteceria se vocé se levantasse e saísse de seu escritório para nunca mais 
voltar? Conheço vários programadores que sentem um certo prazer ao imaginar essa 
cena. Você apenas se levanta, dirige-se à sala de seu chefe, e comunica sua demissão. 
Vou mostrar para eles por que eles precisam de mim! É quase um sonho para 
ajudá-lo a atravessar os dias realmente ruins, mas obviamente não é uma atitude 
muito inteligente para se ter com você o tempo todo. 

Além disso, não é verdade. Pessoas deixam empresas todos os dias. Muitas de- 
las são despedidas. Muitas escolhem se demitir. Algumas ainda tentam viver suas 
ilusões e saem sem aviso prévio. Mas em alguns casos, as empresas que eles deixam, 
na verdade, sentem um impacto significante depois de suas saídas. Na maioria dos 
casos, mesmo em posições críticas, o efeito é surpreendentemente baixo. Sua pre- 
sença no trabalho é, para a empresa, como uma pedrinha em um balde d'água. É 
claro que o nível da água é mais alto como resultado. Você faz as coisas. Você faz sua 
parte. Mas, se você tirar a pedrinha do balde e se afastar para olhar a água, você não 
consegue realmente ver a diferença. 
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Náo estou tentando deixar vocé deprimido. Todos nós precisamos sentir que 
nossas contribuigöes significam alguma coisa. E elas significam. Mas passamos tanto 
tempo sendo um eu, que podemos facilmente esquecer que todos os outros sáo um 
eu também. Todos os funcionários de sua empresa andam por aí, um ser sensível e 
autónimo, presos a esta coisa chamada ego, que é a única janela pela qual eles veem 
seus empregos. Pense assim: se você se demitisse amanhã, a diferença seria (em 
média) náo mais nem menos impactante que se algum de seus colegas saísse. 

Uma vez trabalhei para um CIO que era um dos mais poderosos em uma das 
maiores empresas do mundo. Ele e sua equipe (da qual eu fazia parte) recebiam todos 
os prémios e estabeleciam todos os padróes de TI da empresa. Esse era um cara que, 
obviamente, tinha descoberto algum tipo de elixir mágico e o estava distribuindo em 
almoços e jantares que ele oferecia. 

Um dos poucos conselhos que eu já recebi deste CIO — e eu o ouvi várias vezes 
— é que você nunca deveria ficar muito confortável. Ele declarou que, todo dia ao 
acordar, ele intencional e explicitamente lembrava-se que ele podia ser tirado de seu 
pedestal a qualquer dia. Hoje pode ser o dia, ele dizia. 

Seus funcionários olhavam para ele, incrédulos. Não. Hoje não pode ser o dia. 
As coisas estão indo tão bem. Tem muita coisa acontecendo para você. 


Tenha cuidado para não se cegar com o próprio sucesso. 


Este era o ponto. Humildade não é apenas algo que desenvolvemos para alegar 
que somos mais espirituais. Ela também nos permite ver nossas ações mais clara- 
mente. O que nosso CIO estava nos ensinando era que quanto mais bem sucedido 
você é, é mais provável que você cometa um erro fatal. Quando várias coisas es- 
tão acontecendo para você, é menos provável que você questione seu próprio jul- 
gamento. Quando a maneira como você sempre fez sempre funcionou, é menos 
provável que você reconheça que um jeito novo pode funcionar melhor. Você se 
torna arrogante, e com isso desenvolve pontos cegos. Quanto mais insubstituível 
você pensa que é, mais substituível você é (e você se torna menos desejável). 

Sentir-se insubstituível é um mau sinal, especialmente sendo um desenvolvedor 
de software. Se você não pode ser substituído, isso provavelmente significa que você 
realiza tarefas de tal modo que os outros não conseguem fazer. Mesmo que todos 
nós gostaríamos de ser considerados algum tipo de gênio especial, poucos desenvol- 
vedores de softwares são tão inigualáveis que, de fato, deveriam ser insubstituíveis. 
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Já ouvi vários programadores meio que brincando sobre criar uma “segurança 
de emprego” com código náo manutenível. E vi programadores realmente tentarem 
fazer isso, por incrível que pareça. Em todos os casos, essas pessoas viraram alvos. 
Claro, era assustador para a empresa finalmente demiti-los. Tentar ser insubstituível 
é uma estratégia defensiva que cria um relacionamento hostil com seu empregador 
(e com seus colegas) onde antes não existia. 

Usando essa mesma lógica, tentar ser substituível devia criar um relacionamento 
de trabalho não hostil. Todos nós somos substituíveis. Aqueles de nós que abraçam 
essa ideia e mesmo trabalham em direção a isso, na verdade, diferenciam-se e, não 
intuitivamente melhoram suas próprias chances. 


Faça algo 


1) Faça um inventário do código que você escreveu ou que você mantém e todas as 
tarefas que você realiza. Anote qualquer coisa em que a equipe é completamente 
dependente de você. Talvez você seja o único que entende totalmente do pro- 
cesso de desenvolvimento de sua aplicação. Ou há uma seção do código que você 
escreveu que é especialmente difícil para o resto da equipe entender. 


Cada um desses itens vai para sua lista de tarefas. Documentar, automatizar, ou 
refatorar cada pedaço de código ou tarefa, de modo que eles possam ser facil- 
mente compreendidos por qualquer um de sua equipe. Faça isso até que você 
complete a lista original. Compartilhe proativamente esses documentos com sua 
equipe e com seu líder. Certifique-se de que os documentos sejam guardados em 
algum lugar para que permaneçam de fácil acesso à equipe. Repita esse exercício 


periodicamente. 
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CAPÍTULO 27 


Aprenda a amar manutenção 


Muitos anos atrás, eu estava engajado em fazer um centro de desenvolvimento de 
software para 250 pessoas, do zero. Comegamos com um prédio vazio e fomos de- 
signados a contratar e montar toda a equipe de desenvolvimento. Nesse processo, 
a gente se deparou com um desafio inesperado. Todos queriam fazer novos siste- 
mas. Ninguém queria manter sistemas antigos. Queríamos criar um novo ambiente 
com uma nova cultura energizada, entáo tinhamos de prestar atengáo ao que nossos 
novos funcionários queriam, se iríamos começar no caminho certo. 

Todo mundo gosta de criar. É quando sentimos que nos é dada a oportunidade 
de realmente deixar nossa marca em um trabalho. Sentir que nós somos seu dono. 
Expressarmo-nos através de nossa criação. Nós também tendemos a acreditar que os 
projetos novos são os mais visíveis para nossas empresas. As pessoas que constroem 
a nova geração são as que devem receber o mérito, certo? Eu sabia que essa atitude 
prevalecia entre os programadores com quem eu havia trabalhado anteriormente. 
Mas, lidando com mais de duzentos desenvolvedores, vi isso levado a um extremo 
que eu nunca esperava. 
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Embora desenvolvedores de software sejam tipicamente criativos, pessoas aman- 
tes de liberdade, a “sociedade” de programadores é surpreendentemente como a de 
castas. Programadores querem ser designers, que querem ser arquitetos, e assim por 
diante. Dar manutenção não proporciona nenhuma badge nem um papel maior, 
como um arquiteto, para contar para seus pais e colegas de faculdade. 

Entáo, os fatores de motivacäo säo a habilidade de ser criativo e a chance de dar 
passos em direção a uma promoção. O engraçado é que trabalhar em projetos novos 
não necessariamente é o melhor lugar para fazer ambos. 

Dar manutenção geralmente significa viver em um mundo cheio de sistemas ve- 
lhos e deteriorados, e usuários finais insistentes. Uma vez que o software é tido como 
feito, os departamentos de TI geralmente se focam em reduzir o custo de manuten- 
ção desses sistemas, de modo que possam buscar a maneira mais barata possível para 
mantê-los funcionando. 

Isso geralmente se soma a pouquíssimos recursos destinados a cuidar dos siste- 
mas e a investimentos insignificantes de dinheiro direcionado a rejuvenescê-los. 

Trabalhar em um projeto novo, por outro lado, é onde você começa com um 
mundo novo, limpo e verde. Em uma empresa bem administrada, cada projeto con- 
tribui para fazer, ou economizar, dinheiro, assim os projetos são geralmente financi- 
ados de modo suficiente para serem concluídos (embora experiências possam variar 
aqui). Não há um campo minado de código antigo obrigando os programadores a 
andarem cuidadosamente nas pontas dos pés para poderem desenvolver funciona- 
lidades corretamente, com menos empecilhos do que se estivessem trabalhando em 
um sistema legado. Em suma, as circunstâncias nos projetos novos são geralmente 
muito mais ideais. 

Se eu lhe der mil reais e pedir que me traga uma xícara de café, ficarei muito triste 
se você voltar com menos mil reais e nenhuma xícara de café. Eu ficarei triste até se 
você me trouxer um café realmente bom, mas demorar duas horas. Se eu não lhe der 
dinheiro e pedir uma xícara de café, ficarei extremamente grato se você efetivamente 
voltar com um café, e serei compreensivo se não. Trabalhar em um projeto novo é 
como o primeiro cenário. Manutenção é como o segundo. 

Quando não temos as restrições do código legado ruim e de falta de fundos, 
nossos gerentes e clientes legitimamente podem esperar mais de nós. E, em pro- 
jetos novos, há uma melhoria de negócio esperada. Se nós não entregarmos, nós 
falhamos. Uma vez que nossas empresas estão contando com essas melhorias, eles 
vão frequentemente apertar as rédeas naquilo que for criado, como, e para quando. 
De repente, nosso playground de criatividade começa a parecer mais uma operação 
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militar — qualquer movimento nosso é ditado de cima. 


Manutengäo pode ser um lugar de liberdade e criatividade. 


Mas no lado da manutenção, tudo o que é esperam que façamos é manter o soft- 
ware rodando sem problemas e com o mínimo custo possível. Ninguém espera nada 
chamativo da equipe de manutenção. Tipicamente, se tudo estiver indo certo, os 
clientes ficarão alheios a seu trabalho. Consertar erros, implementar pequenas soli- 
citações de funcionalidades, e mantê-las rodando. Isso é tudo que você precisa fazer. 

E se um erro aparece e exige que se refaça uma parte da aplicação? Isso é tudo 
parte do conserto de erros, certo? O design deve estar antigo e embolorado, e janelas 
quebradas devem estar espalhadas pelo sistema. 





TEORIA DAS JANELAS QUEBRADAS 


Para conhecer a teoria das janelas quebradas, você pode ler o livro The 
Pragmatic Programmer [7]. 











Ai esta uma oportunidade de colocar suas refatoragöes em teste. Quäo elegante 
esse sistema pode ser? Quanto mais rapido vocé pode consertar ou aprimorar esta 
seção na próxima vez devido à refatoração que você está fazendo agora? 

Enquanto você continuar a mantê-lo rodando e respondendo às solicitações dos 
usuários em tempo hábil, o modo de manutenção é um lugar de liberdade e criati- 
vidade. Você é líder de projeto, arquiteto, designer, programador e testador. Você 
pode modelar suas habilidades criativas da forma de que gosta, e é você quem vai 
suportar os sucessos ou as falhas do sistema. 

Quando você está fazendo a manutenção de um sistema, você também pode 
planejar melhorias mais visíveis. Seu sistema web de 3 anos de idade pode não levar 
vantagem de algumas das novas interfaces impertinentes de usuário disponíveis para 
os browsers modernos. Se você pode trabalhar entre manter o sistema rodando e 
consertar os erros, você poderia visivelmente aprimorar a experiência do usuário 
com o sistema. Adicionar algumas funcionalidades bem colocadas que seus clientes 
não estavam esperando não é tão diferente do que surpreender sua esposa com flores, 
ou, enquanto criança, limpar a casa quando seus pais estão fazendo compras. E, sem 
a burocracia de um projeto em pleno desenvolvimento, você se surpreenderá com 
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o quanto vocé pode se encaixar nesses pequenas frestas. Seus clientes também se 
surpreenderáo. 

Uma vantagem oculta de dar manutenção é que, diferente do ambiente contra- 
tual de muitos dos projetos atuais, o programador que dá manutenção geralmente 
tem a oportunidade de interagir diretamente com seus clientes. Isso significa que 
mais pessoas saberáo quem vocé é, e vocé terá a chance de construir uma base mais 
larga de defensores em seu negócio. Isso também o coloca em um lugar especial para 
verdadeiramente aprender o funcionamento interno do seu negócio. 

Se você é responsável por uma aplicação em sua totalidade, sempre trabalhando 
com seus usuários finais através dos problemas e questões, há mais chances de que, 
mesmo sem muito esforço, você entenda o que a aplicação realmente faz tão bem 
quanto muitos de seus usuários. Regras de negócio são implementadas em uma ló- 
gica que mesmo pessoas de negócio não conseguem entender. Já vi muitas situações 
em que só os programadores que entendiam como um processo específico funci- 
onava em uma empresa. Ninguém mais tinha exposição direta ao código daquela 
lógica. 

A grande ironia em relação à separação de projeto versus manutenção é que tra- 
balhar em projeto novo é manutenção. Assim que sua equipe de projeto escreveu 
a primeira linha do código, cada funcionalidade adicional está sendo enxertada em 
uma base de código vivo. Claro, o código deve ser o mais limpo ou deve ser menor 
do que se você estivesse trabalhando em uma aplicação legada, mas o ato básico é o 
mesmo. Novas funcionalidades são adicionadas e erros são consertados no código 
existente. Quem sabe como fazer isso melhor e mais rápido do que alguém que real- 
mente adotou o ato de dar manutenção e estabeleceu como missão aprender a fazer 
isso direito? 


Faça algo 


1) Meça, melhore, meça — Para a aplicação ou o código mais crítico que você man- 
tém, faça uma lista de fatores mensuráveis que representam a qualidade da apli- 
cação. Isso pode ser o tempo de resposta, número e exceções não tratadas que são 
lançadas durante o processamento, ou tempo de atividade da aplicação. Ou, se 
você cuida do suporte, não avalie diretamente a qualidade da aplicação. O tempo 
que você leva para responder ao chamado é uma parte importante da experiência 
do usuário com a aplicação. 


Escolha os mais importantes desses atributos mensuráveis, e comece a medi-los. 
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Depois que você tiver uma boa base, estabeleça um objetivo realista e melhore 
a performance da sua aplicação (ou sua própria performance) para alcançar esta 
meta. Depois de ter feito uma melhoria, meça mais uma vez para verificar que 
você realmente fez a melhoria desejada. Se sim, compartilhe isso com sua equipe 
e seus clientes. 


Escolha uma outra métrica e faça isso mais uma vez. Depois da primeira, você 
descobrirá que isso se torna divertido, como um jogo. Aprimorar coisas de modo 
mensurável como este se torna viciante. 
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CAPÍTULO 28 


Maratona de oito horas 


Uma das diversas fontes de controvérsia a respeito do movimento Extreme Program- 
ming é sua declaragäo inicial de que os membros da equipe náo deveriam trabalhar 
mais que quarenta horas por semana. Esse tipo de conversa realmente contraria ge- 
rentes escravocratas que querem espremer o máximo de produtividade possível de 
suas equipes. Isso pode chatear até mesmo os programadores. O número de horas de 
trabalho contínuo se torna parte da masculinidade do desenvolvedor, como quantas 
cervejas alguém pode virar em uma cervejada. 

Bob Martin (http://www.objectmentor.com) , um dos grandes nomes da comu- 
nidade de Extreme Programming, inverteu essa sentenga de tal forma que a tornou 
muito mais tolerável por ambas as partes, enquanto ainda se mantinha fiel ao intento 
original de Kent Beck. Martin renomeou quarenta horas de trabalho semanais para 
“maratona de oito horas”. A ideia é que vocé deveria trabalhar com tanto afinco que 
náo seria possível continuar por mais tempo do que oito horas. 

Antes de vocé mergulhar na maratona, por que a énfase em manter o número 
de horas baixo de qualquer maneira? Este capítulo é sobre terminar coisas. Náo 
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deveríamos estar conversando sobre trabalhar por mais horas? 

Quando se trata de trabalho, menos realmente pode ser mais. O primeiro motivo 
citado pelos Extreme Programmers é que, quando estamos cansados, náo consegui- 
mos pensar táo efetivamente quanto quando estamos descansados. Quando estamos 
esgotados, náo somos táo criativos, e a qualidade do nosso trabalho se reduz drama- 
ticamente. Começamos a cometer erros estúpidos que acabam nos custando tempo 
e dinheiro. 


Projetos são maratonas, não corridas de velocidade. 


A maioria dos projetos dura bastante tempo. Você não consegue manter o ritmo 
de um arranque e terminar uma maratona. Embora sua produtividade a curto prazo 
vá aumentar significativamente conforme conta as horas, a longo prazo você vai de- 
cair tão gravemente que o tempo de recuperação será mais longo do que os ganhos 
de produtividade que você aproveitou durante suas semanas de oito horas. 

Você também pode pensar em seu tempo da mesma maneira que você pensa de 
seu dinheiro. Quando eu era um adolescente, trabalhava meio período por salário 
mínimo. Eu teria sido muito feliz se tivesse a quantidade de dinheiro que eu gasto 
agora. Eu tenho tanto mais dinheiro agora do que quando adolescente, que eu tendo 
a ser menos consciente com como eu gasto cada dólar. De alguma forma, eu conse- 
guia sobreviver naquele tempo. Eu tinha um lugar para viver, um carro para dirigir, 
e comida para comer. 

Eu tenho as mesmas coisas hoje. E eu não tenho um estilo de vida particular- 
mente extravagante agora. Aparentemente, quando dinheiro era escasso, eu dava 
um jeito de ser mais eficiente com o que eu ganhava. E o resultado final era essenci- 
almente o mesmo. 

Nós tratamos os recursos escassos como sendo mais valiosos, e fazemos uso mais 
eficiente deles. Somando-se à questão de dinheiro, podemos aplicar isso para nosso 
tempo. Pense no quarto dia da sua última semana de setenta horas de trabalho. Sem 
dúvidas, você estava realizando fazendo um baita esforço. Mas a partir do quarto 
dia, você começa a afrouxar. São 10h30 da manhã, e eu sei que estarei aqui por 
quatro horas depois que todos os outros vão para casa. Quer saber, acho que vou 
dar uma olhada nas últimas notícias de tecnologia. 

Quando você tem muito tempo para trabalhar, seu tempo de trabalho se reduz 
significativamente em valores percebíveis. Se você tem setenta horas disponíveis, 
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cada hora é menos preciosa para vocé do que quando vocé tem quarenta horas dis- 
poníveis. 

Quando o valor do dólar sofre uma inflação, são necessários mais dólares para 
comprar a mesma coisa. Quando o valor da hora é deflacionado, você precisa de 
mais horas para fazer coisas. A maratona de oito horas de Bob Martin estabelece 
uma limitação e lhe oferece uma estratégia para lidar com essa restrição. Você vai 
trabalhar e pensa: Eu só tenho oito horas! Vai, vai, vai! Com barreiras estreitas 
nos horários de início e fim, você naturalmente começa a organizar seu tempo mais 
eficazmente. Você pode começar com um conjunto de tarefas que precisam ser con- 
cluídas no dia, organizá-las em ordem de prioridade, e começar a finalizá-las uma 
de cada vez. 

A maratona de oito horas cria um ambiente que se parece com aquele final de se- 
mana ultraprodutivo que você possivelmente teve na época da faculdade, estudando 
para uma prova de uma matéria que você não estava nem aí ou deixando de lado um 
trabalho para a última hora por pura preguiça. A diferença é que este é um acúmulo 
limitado. Esses momentos em que você corre atrás são extremamente produtivos, 
porque o tempo se torna escasso e, portanto, bastante valioso. A maratona de oito 
horas é um método de estar sobrecarregado frequentemente, sem ter que ficar acor- 
dado a noite inteira à base de Ritalina e bebendo Coca Cola. 

Como trabalhadores mentais, mesmo se não estamos na frente de um compu- 
tador ou no escritório, podemos estar trabalhando. Você pode estar trabalhando 
enquanto dirige para jantar com sua esposa ou enquanto você assiste a um filme. 
Seus deveres ficam seguindo-o e incomodando-o. 

Meu trabalho geralmente me incomoda quando eu não prestei atenção suficiente 
a ele. Posso ter deixado alguma tarefa escapar ou deixado-as acumular, não cuidado 
delas. É esse o momento que o trabalho me persegue até em casa e me cutuca quando 
tento relaxar. Se seu trabalho se intensifica todo dia, você vai descobrir que ele não 
o persegue até em casa. Não somente você está deliberadamente se impedindo de 
trabalhar horas-extras, mas sua mente vai realmente permitir que você pare de fazer 
horas-extras. 

Faça o orçamento de seu trabalho cuidadosamente. Trabalhe menos, e você rea- 


lizará mais. Trabalho é sempre mais bem-vindo quando você se deu um tempo longe 
dele. 


Faça algo 
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1) Certifique-se de que você durma bem hoje. Amanhã, tome o café da manhã e, 
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entáo, comece a trabalhar em um horário exato (de preferéncia, um pouco mais 
cedo que o usual). Trabalhe intensivamente por quatro horas. Tire uma hora para 
almogar. Entáo, trabalhe por mais quatro horas táo intensamente que vocé fique 
absolutamente exausto e náo consiga fazer mais. Vá para casa, relaxe, e divirta-se. 


CAPÍTULO 29 


Aprenda a falhar 


Como programadores, sabemos que, quanto mais cedo no processo de desenvolvi- 
mento conseguimos descobrir falhas de software, mais robusto ele vai ficar. Testes 
de unidade nos ajudam a desentocar erros estranhos o mais cedo possível. Se encon- 
trarmos erros bizarros em nosso código, e se isso acontecer cedo, ficaremos felizes. 
Embora eles signifiquem uma pequena falha em nosso papel como desenvolvedores 
- afinal cometemos uma falha de programação - descobri-los cedo e frequentemente 
é um bom sinal da saúde do software que vocé vai ter. 

Somos ensinados a permitir que nossos erros de programação sejam grandes e 
bagungados desde cedo. Vocé quer saber quais eles sáo e em qual momento eles 
acontecem, para que você faça as correções necessárias. Quando você esta escre- 
vendo código, vocé náo desvia do seu caminho para esconder as pequenas falhas de 
software que estáo destinadas a aparecer durante o desenvolvimento. Esta é a forma 
de o código conversar com vocé. Aquelas pequenas falhas sáo parte do processo de 
fortalecimento do software. 


As pequenas falhas que encontramos também nos ensinam que tipo de falhas 
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esperar. Se vocé nunca andou em um campo minado antes, vocé pode náo saber as 
protuberáncias ou sujeiras nas quais náo pisar. Se seu software náo tem dado erro re- 
gularmente, vocé pode náo saber onde os problemas podem estar. E além disso, vocé 
pode até programar muito defensivamente, colocando diversas verificagöes, mas se- 
ria o mesmo que se estivesse programando ás cegas. 

Além disso, claro, é importante programar defensivamente. A qualidade do soft- 
ware é realmente colocada à prova quando as coisas dao errado. É inevitável que al- 
guma coisa vai acontecer para um cenário que vocé náo percebeu. Seg-faults e telas 
azuis em producäo mostram que os programadores náo fizeram um bom trabalho 
de lidar com as situações que eles não puderam prever. 

Os mesmos princípios se aplicam ao emprego. Alguém que faz trabalhos ma- 
nuais é realmente colocado à prova quando surgem os erros. Aprender a lidar com 
os erros é uma habilidade altamente valiosa e difícil de se ensinar. Como músico 
improvisador de jazz, aprendi que toda nota errada é no máximo um tom distante 
de uma nota certa. O que torna os improvisos ruins é quando o improvisador não 
sabe o que fazer quando a nota errada aparece. Com uma banda de um lado e o pú- 
blico do outro, o som de uma nota errada é suficiente para travar um amador. Até os 
mestres tocam notas erradas. Mas eles se recuperam de tal forma que o ouvinte não 
consegue notar se a coisa toda não foi intencional. 

Todos nós vamos cometer erros estúpidos no trabalho. Faz parte do ser humano. 
Cometemos erros que fazem os clientes verem stack traces. Nós nos penitenciamos 
quando cometemos erros graves de design. Ou, pior ainda, dizemos as coisas erradas 
para as pessoas da nossa equipe, chefes e clientes. Traçamos maus compromissos ou 
fazemos afirmações falsas sobre o que somos capazes de fazer. Ou acidentalmente 
damos um mau conselho à equipe sobre como resolver um problema técnico, des- 
perdiçando horas de seu tempo. 

Porque todos nós cometemos erros, e também sabemos que todo mundo comete 
erros. Logo, com razão, não julgamos uns aos outros nos erros que cometemos. 
Julgamo-nos sobre como lidamos com esses erros inevitáveis. 

Seja um erro técnico, de comunicação, ou de gerência de projeto, as seguintes 
regras podem ser aplicadas: 


e Levante o assunto logo que souber. Não tente esconder. Em desenvolvimento 
de software e testes, erros descobertos antes são um problema menor do que 
erros descobertos tarde. O mais cedo que você expuser o que tiver feito, menos 
negativo o impacto deve ser. 
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e Leve a culpa. Não tente procurar por um bode expiatório mesmo se você en- 
contrar um que sirva. Mesmo se a culpa não for completamente sua, assuma 
a responsabilidade e continue em frente. O objetivo é passar desse ponto o 
mais rápido possível. Um problema precisa de uma resolução. Prolongá-lo 
discutindo de quem é a culpa apenas atrasa a solução. 


e Ofereça uma solução. Se você não possui uma, ofereça um plano de ataque 
para descobrir uma solução. Fale em termos concretos e prazos previsíveis. 
Se você tiver conduzido sua equipe a um canto, dê prazos para quando você 
retornará com a avaliação do esforço necessário para corrigir o problema. Me- 
tas concretas e alcançáveis, mesmo se pequenas e imateriais, são importantes 
nesse estágio. Não apenas elas mantêm as coisas em funcionamento, de mau 
para bom, mas também ajudam a reconstruir a credibilidade no processo. 


e Peçaajuda. Mesmo se você for o único culpado de um problema, não deixe seu 
orgulho piorar a situação, recusando ajuda em uma solução. Os membros de 
sua equipe, chefes e clientes vão olhar para você de um ângulo mais positivo se 
você conseguir manter uma atitude saudável e deixar seu ego de lado enquanto 
a equipe ajuda a encontrar a saída. Muito frequentemente, sentimos um senso 
de responsabilidade que nos faz suportar orgulhosamente um fardo pesado 
demais, e acabamos travados até que alguém intervenha. 


Pense na última vez em que você teve um problema em um restaurante. Talvez 
você esperou demais até o prato errado finalmente chegar à sua mesa. Pense sobre 
como o garçom reagiu à sua reclamação. 


Momentos de estresse oferecem as melhores oportunidades de construir fidelidade. 


A reação errada seria se o garçom desse desculpas ou culpasse os cozinheiros. 
A reação errada seria o garçom sair andando e reenviar o pedido, e ficar fora do 
seu campo de visão por um tempo, enquanto você continua lá com fome e pensando 
quando é que sua comida vai chegar. Claro, a reação realmente errada seria o garçom 
chegar com um prato que ele já sabe que é o errado, esperando que você não repare 
ou não reclame. 

A diferença entre como uma empresa nos trata quando houve um erro pode ser a 
última palavra em construir fidelidade (ou destruir). Um erro com o qual for bem li- 


dado pode tornar-nos consumidores mais fiéis do que seríamos se nunca tivéssemos 
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experienciado o problema de servigo. Lembre-se disso com seus clientes quando 
cometer erros no trabalho. 
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CAPÍTULO 30 


Diga “Nao” 


O jeito mais fácil de náo cumprir com seus compromissos é se comprometer com o 
que você sabe que não conseguirá cumprir. Eu sei que, evidentemente, isso soa óbvio, 
mas nós fazemos isso todo dia. Estamos á vista de todos e náo queremos desapontar 
nossos líderes, entáo aceitamos o compromisso de realizar trabalhos impossíveis em 
prazos inviáveis. 


Dizer “sim” para evitar desapontamento é apenas mentir. 


Dizer “sim” é um hábito viciante e destrutivo. É um mau hábito mascarado como 
bom. Mas existe uma grande diferenga entre uma atitude “posso fazer” e a deturpa- 
cáo da capacidade de alguém. Esta última causa problemas náo apenas para vocé 
mas para as pessoas para quem vocé está fazendo promessas. Se eu sou seu gerente 
e pergunto se vocé pode reescrever o modo como rastreamos remessas no sistema 
da empresa até o fim do més, é provável que eu tenha perguntado especificamente 
sobre o fim do més por alguma razáo. Alguém provavelmente perguntou a mim se 
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isso poderia ser feito até lá. Ou deve haver outra mudanga crítica de negócios que 
estamos tentando fazer que depende do sistema. Entáo, munido de sua garantia de 
que vocé pode conseguir nesse prazo, eu saio e falo aos meus clientes que isso será 
feito. 

Dizer “sim” desse jeito é tão bom quanto mentir. Não estou dizendo que é malici- 
oso. Nós mentimos para nós mesmos tanto quanto para aquelas pessoas com quem 
nos comprometemos. Afinal, dizer “não” nos faz sentir mal. Somos programados a 
sempre querer obter sucesso. E, dizer que nós não conseguimos fazer alguma coisa 
dá a sensação de que falhamos. 

O que nós, humanos, não conseguimos absorver é que “sim” não é sempre a 
resposta certa. E “não” é raramente a resposta errada. Eu digo absorver, porque eu 
acho que todos nós sabemos que isso é verdade. Afinal, nenhum de nós quer receber 
falsos compromissos. 

A inabilidade de dizer “não” é uma parte comum da cultura indiana. Empre- 
sas sem experiências em terceirizações offshore quase sempre vão em direção a isso. 
Você aprende com o tempo a farejar incertezas e faz as perguntas certas. Conver- 
sas do tipo “mais um dia para isso estar pronto” naturalmente o treinam a sondar 
mais profundamente. E isso não é apenas parte da cultura de TI. Quando morei em 
Bangalore, deixei de ir ao trabalho e fiquei em casa não menos do que cinco vezes, 
à espera de uma instalação do modem a cabo que nunca aconteceu. Nas primeiras 
três vezes, a empresa nem possuía os aparelhos necessárias para a instalação quando 
fizeram o agendamento. Mas eles não queriam me desapontar. Eu disse que espe- 
rava ter o modem instalado até a próxima semana, então eles me prometeram que 
a instalação seria feita, sabendo muito bem que isso não ia ser possível na próxima 
semana. 

Embora a intenção fosse boa, as ramificações foram negativas. Eu eventualmente 
fui desagradável com os instaladores e até mesmo fiz com que viessem à minha casa 
para fazer a instalação em um feriado. Não confiei na promessa de que o fariam 
“amanhã, depois do feriado”. O fato de terem falhado repetidamente com seus com- 
prometimentos destruiu qualquer possibilidade que eu tinha de confiar neles. Além 
disso, eu fui desenvolvendo uma atitude de hostilidade em relação a eles. 

Por outro lado, o que acontece quando lhe pedem que faça uma tarefa crítica e 
você diz que não pode? Como gerente tanto de equipes onshore como de offshore, 
posso lhe dizer que “não” se tornou uma fonte de alívio para mim. Se um membro 
da equipe tem a coragem de dizer “não” quando esta é a verdade, então eu sei que 
quando eles dizem “sim”, eles realmente querem dizer isso. Um comprometimento 
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de uma pessoa assim será mais creditável e terá mais peso. Se eles realmente alcanca- 
rem seus objetivos com os quais se comprometeram, náo vou questioná-los quando 
disserem que náo podem alcangar outro. 

Se alguém sempre diz “sim”, ele é ou incrivelmente talentoso ou está mentindo. 
Este último é geralmente o caso. 

“Eu não sei” também é uma ótima coisa a dizer quando apropriado. Essa pode 
ser uma resposta para se você consegue cumprir tal prazo e precisa de tempo para 
pesquisar a tarefa antes de estabelecer qualquer compromisso. Ou você pode ser 
questionado sobre como uma tecnologia funciona ou como alguma parte do código 
do seu projeto é implementada. Assim como no caso dos comprometimentos, não 
saber a resposta de algo dá a sensação de uma pequena falha. Mas seus colegas de 
trabalho e seus chefes terão mais fé em você quando você alegar saber alguma coisa. 
Você notará que, quando encontrar um guru real em determinada área, ele nunca 
terá medo de admitir quando não sabe algo. “Eu não sei” não é uma frase para gente 
insegura. 

A mesma coragem também pode aparecer convenientemente quando estiver li- 
dando com decisões vindas de cima. Quantas vezes você viu uma decisão de tecno- 
logia ditada por um chefe que fez os membros da equipe sentarem ao redor da mesa 
silenciosamente olhando para seus sapatos e esperando uma chance para escapar da 
sala de reunião, para poderem reclamar uns com os outros? Gerentes são geralmente 
o alvo do fenômeno A roupa nova do rei (Emperors New Clothes). Todo mundo sabe 
que uma decisão é ruim, mas todos estão com medo de se pronunciar. Entretanto, 
eu não contrato meus funcionários para serem robôs. São os que se pronunciam e 
oferecem uma sugestão melhor que se tornam meu acessores confiáveis. 

Não vá muito além com o jogo do “não”. Atitudes de “poder fazer” ainda são 
bem-vindas, e é bom ter metas ambiciosas. Se você não tem certeza se consegue 
fazer alguma coisa, mas quer tentar, diga isso. “Isso será um desafio, mas eu gostaria 
de tentar” é uma resposta maravilhosa. Às vezes, é claro, a resposta é simplesmente 


Tenha coragem o suficiente para ser honesto. 
Faça algo 


1) Karl Brophey, um crítico, sugere manter uma lista de tudo o que você se compro- 
meteu: 


+ O que foi pedido com uma data limite? 
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e Com o que você se comprometeu? 


e Se você está atrasado, registre tanto o que você fez e o que lhe mandaram 
fazer. 


e Registre quando você cumpriu o dever. 
Examine isso diariamente. Comunique quando você falhará assim que você per- 


ceber. Examine isso mensalmente — qual sua média de sucesso? Com qual 
frequência você está correto? 


CAPÍTULO 31 


Náo entre em pánico 


Eu comecei minha carreira de programador por causa de vídeo games. Desde a época 
dos cartuchos com meu Commodore 64, eu fui conquistado pelas experiéncias imer- 
sivas einterativas. Eu costumava ter vergonha de admitir isso, mas agora percebo que 
náo é nada para se envergonhar. Para mim, jogos de computador fizeram do ambi- 
ente on-screen (do sistema operacional, eu acho) um ambiente em que eu me sentia 
confortável e disposto. 

Meu jogo favorito de todos os tempos era Doom, da ID Software. Eu era apai- 
xonado pelas modos de one-on-one, jogador vs. jogador e combates mortais. Os 
jogadores se conectavam via modem ou conexáo serial, e lutavam entre si em um 
pequeno e acelerado ambiente. Eu fiquei bom nos combates mortais do Doom. Eu 
dizia que isso devia ser o que eu melhor sabia fazer da minha vida. O jogo de com- 
bate mortal é surpreendentemente complexo. É tanto técnico como psicológico — 
como uma mistura frenética de xadrez e esgrima. 

Assim como para a maioria das habilidades, uma ótima maneira de se tornar 
bom é assistir os mestres. Lá na minha época de Doom, havia um mestre que possuía 
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o pseudónimo irónico de “Noskill” (Sem habilidades, em inglés). Noskill era, de 
fato, o campeáo de Doom. Pessoas dos Estados Unidos e Canadá pagavam tarifas 
telefónicas de longa distáncia para tentar a sorte contra ele. Esses combates eram 
gravados. Eu assistia a todos. 

Náo levou muito tempo para eu aprender seu segredo. Claro, no geral ele era 
bom no jogo, mas havia uma chave óbvia para seu sucesso: ele nunca entrava em 
pánico. Doom era o tipo de jogo em que uma partida podia terminar em, literal- 
mente, segundos depois de comegar. Era realmente rápido. Eu me lembro do meu 
primeiro jogo de combate mortal. Começa, morre, começa, morre, começa, morre. 
Quando eu finalmente consegui ficar vivo por mais do que dois segundos, peguei-me 
correndo sem rumo, mal sendo capaz de acompanhar onde eu estava. 

Mas Noskill nunca agia dessa forma. Não importava quão difícil era a situação, 
você podia notar ao assistir às gravações que ele estava sempre relaxado e sempre 
pensando no que fazer em seguida. Ele sempre aparentava estar ciente de como seu 
contexto atual se encaixava no formato geral da partida. 


Heróis nunca entram em pânico. 


Agora, se você pensar em outros jogos, em particular esportes, você vai reco- 
nhecer que todos os melhores jogadores compartilham dessa qualidade. Aliás, até 
mesmo os personagens que admiramos nos livros, na televisão e nos filmes compar- 
tilham dessa qualidade. Heróis nunca entram em pânico. Eles são sempre as pessoas 
que podem ter uma bomba nuclear caindo sobre sua cidade, ou ter um acidente de 
avião, e conseguem organizar um grupo, ajudar os sobreviventes, ser mais esperto 
que o inimigo, ou pelo menos, apenas não se desabar em lágrimas. 

Isso se estende à vida real também. Apesar do meu melhor planejamento, mi- 
nha vida profissional tem sido uma corrente de emergências e desastres. Projetos 
são concluídos bem tarde. Softwares dão problemas, custando dinheiro e credibili- 
dade dos meus chefes. Eu digo a coisa errada para o vice-presidente errado e ganho 
um inimigo político. Na maioria das vezes, essas coisas vêm em ondas todas juntas, 
nunca uma por vez. 

Em meus piores momentos, eu entro em pânico. Eu travo e, na melhor das hipó- 
teses, consigo pensar taticamente. Reajo a cada pequeno movimento sem a clareza 
de considerar o grande cenário. 

Mas olhando para trás para, literalmente, cada desastre, nenhum teve um im- 
pacto duradouro e notável em mim ou em minha carreira. Portanto, por mais que 
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eu tenha ficado em pánico, depressivo ou chateado nessas situagöes aparentemente 
desastrosas, nenhuma foi realmente um verdadeiro desastre. 

O que o pánico trouxe para mim? Qual foi a vantagem de reagir negativamente 
para cada uma dessas situações? Nada. O que o pánico realmente me deu foi uma 
inabilidade de agir no meu melhor nas vezes em que eu realmente precisava dar o 
meu melhor. 

Agora eu tenho que admitir que náo entrar em pánico em situagöes estressantes 
é mais fácil de se dizer do que fazer. É quase como dizer para alguém: “simplesmente 
seja feliz”. É claro, é um bom conselho, mas como se faz isso? Como vocé evita entrar 
em pánico quando as coisas parecem estar desabando? Para responder esta questáo, 
talvez ajude pensar um pouco sobre por que nós entramos em pánico. 

Nós entramos em pánico porque perdemos perspectiva. Quando algo tem dado 
errado, é difícil náo focar toda nossa atengäo no problema. De certa maneira, esse 
é um bom jeito de resolver problemas. Infelizmente, isso também faz o problema, 
náo importa quáo pequeno seja, aparentar ser mais importante do que realmente é. 
E com o problema aumentando, e os níveis de estresse lá em cima, nossos cérebros 
se desligam. 

Quem é o pior usuário de computador que vocé conhece? Para mim, é prova- 
velmente um dos meus sogros (eu sei quem, mas sou esperto o suficiente para náo 
dar nomes aqui). Imagine aquela pessoa sentada com seus computadores tentando 
terminar um projeto quando uma mensagem de erro começa a aparecer com qual- 
quer coisa que eles tentam fazer. Todos nós já vimos isso acontecer. Usuários sem 
experiência ficam rapidamente frustrados e se desesperam. Então começam a fre- 
neticamente clicar e arrastar coisas pela tela, ignorando as mensagens que potenci- 
almente os poderiam ajudar conforme elas continuam aparecendo repetidamente. 
Eles eventualmente ficam táo afobados que precisam pedir ajuda, mas geralmente 
náo antes de bagungar uma ou duas coisas adicionais no computador. 

Näo me leve a mal, mas eu quero que vocé imagine essa situagäo com alguém 
que você conheça, que seja apropriado para o papel principal, e quero que você ria 
disso. Esse tipo de comportamento é realmente ridículo, não? É cômico. 

Mas, por mais genuinamente engraçado que isso seja, o que nós acabamos de 
imaginar foi um cenário da vida real em que uma pessoa, trabalhando fora de sua 
zona de conforto, encontra um problema e entra em pânico. Não é diferente da forma 
como eu reagi quando projetos se atrasaram ou eu acidentalmente causei um bug no 
sistema, ou desapontei um cliente. É apenas um contexto diferente. 


Então, aqui está como eu estou aprendendo a não entrar em pânico. Quando 
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algo ruim acontece, e eu começo a sentir aquela sensação estressante de afundar 
que me levaria ao pánico, eu me comparo àquele frustrado usuário de computador 
inexperiente, e rio de mim mesmo. Eu analiso a situação pela perspectiva da terceira 
pessoa, como se eu estivesse ajudando aquele membro da família que está frustrado 
com seu desastre. Problemas aparentemente difíceis tornam-se repentinamente mais 
fáceis. Situações aparentemente ruins de repente não são tão ruins. E eu sempre 
encontro a solução simplesmente olhando na minha cara, da mesma forma que a 
caixa de diálogo de erro geralmente lhe diz exatamente o que você deve fazer. Se 
você apenas tiver a presença de espírito para ler a mensagem de erro, o problema 
pode ser solucionado. 


Faça algo 


1) Mantenha um diário do pânico. A chave para capturar o pânico antes que ele 
aconteça é desenvolver uma consciência intensificada em tempo real de suas per- 
cepções e emoções conforme elas acontecem. Eu tirei a sorte grande ao aprender 
a fazer isso analisando minhas reações a situações depois do fato. Eu não sou 
esperto o suficiente para manter uma linha constante de analise dos meus pen- 
samentos conforme eles acontecem, mas eu descobri que se eu praticar a análise 
cc . » . . rs 

offline’, eu melhoro cada vez mais para realiza-la em tempo real. 


Dizer que você se empenhará mais em analisar suas reações e realmente fazer isso 
sáo duas coisas bastante diferentes. Manter um diário vai ajudá-lo a adicionar 
estrutura ao processo. Todo dia, em um horário específico (use um calendário 
como um lembrete!), abra um arquivo de texto e registre qualquer situagäo que 
o levou a sentir pánico, mesmo se foi pouco. Uma vez por semana, veja a lista da 
semana passada e mantenha um estoque dos últimos impactos de cada situação 
que induziram ao pânico. A situação valeu o pânico? Qual teria sido a reação 
mais produtiva para a situação? O que um herói, em um filme dramático sobre 
sua vida, teria feito em vez de entrar em pânico? 


Depois de alguma prática, você descobrirá que a análise começa a acontecer en- 
quanto o pânico emerge. Conforme você racionalmente explora as razões do seu 
pânico em tempo real, você descobrirá que o pânico, por si próprio, vai para o 
banco de trás, e eventualmente se dissipa. 
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Diga, faça, mostre 


O jeito mais fácil de nunca tornar algo pronto é nunca se comprometer com nada. 
Se você não tem um prazo, não há nenhuma pressão ou incentivo suficiente para 
concluir algo. Isso é ainda mais verdadeiro quando esse algo que deve ser feito não 
é 100% excitante. 

O instinto de, até mesmo, um mau gerente geralmente diz que é importante pla- 
nejar. Para alguns desenvolvedores, a invocação da palavra planejamento é motivo 
de alarme. Reuniões intermináveis com seus chefes criando e analisando gráficos 
do Microsoft Project, que ninguém entende ou usa, são uma causa válida de alarme. 
Então, os tecnólogos geralmente tentam compensar, como rebelião contra o excesso 
de planejamento, agindo conforme suas próprias decisões, em vez das que foram 
estabelecidas no plano. 

Planejamento não é um remédio tão ruim, daqueles que precisamos tampar o 
nariz para engolir. Ele pode ser uma experiência libertadora. Quando você tem 
muito a fazer, um plano pode fazer a diferença entre um começo de dia de trabalho 
confuso e ambíguo, e a confiança de uma mente limpa ao atacar as tarefas. 
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Planos náo precisam ser grandes e prolongados. Uma lista em um documento 
de texto ou um e-mail é perfeitamente suficiente. Planos náo precisam cobrir um 
longo espaço de tempo. A possibilidade de começar o dia e responder a questão “O 
que você vai fazer hoje?” é um ótimo primeiro passo. Conheço muitas pessoas cujos 
dias começam tão agitados que eles provavelmente falhariam nesse teste. Um bom 
primeiro passo seria achar tempo nessa tarde e listar tudo que você quer concluir 
no próximo dia de trabalho, e organizar em uma lista de prioridades. Tente ser re- 
alista quanto ao que pode fazer em um dia, embora seja provável que você erre e se 
sobrecarregue. 

Você pode ser tão detalhista ou vago quanto quiser com seu plano de um dia. Eu 
tive um colega de quarto na faculdade chamado Chris que acordava todas as manhãs 
e, mesmo com o risco de se atrasar para sua primeira aula, planejava meticulosa- 
mente seu dia, especialmente com foco em seu horário de praticar piano (ele estava 
cursando piano e jazz). Sua agenda já era bastante rígida com a seleção de aulas que 
ele tinha que frequentar. Mesmo assim, Chris realmente fazia um plano sobre como 
ele poderia usar aqueles quinze minutos entre as aulas para encaixar sua rotina de 
treinos que podiam ser feitos rapidamente. 

Muitas de suas aulas eram no mesmo prédio, de modo que era comum ter bas- 
tante tempo de lazer entre elas para socializar ou pegar alguma bebida nas máquinas. 
Nesse tempo, Chris preferia se dedicar às escalas ou a treinar sua audição, enquanto o 
resto de nós ficava sentado esperando a próxima aula começar. Ele até mesmo dividia 
seu horário em múltiplos segmentos de três a cinco minutos, para poder treinar mais 
de um exercício em um dado período de dez minutos. O Chris acabou se tornando 
um dos músicos mais respeitados em nossa cidade. Claro que o talento natural tinha 
algo a ver com isso, mas desde então eu tenho a crença de que ele planejou e executou 
seu caminho para a elite musical. 

Então, você fez seu planejamento. Pode não ser tão detalhado como o do Chris, 
mas é o suficiente para responder a pergunta de o que você vai fazer com seu dia. 
Quando você for trabalhar amanhã, pegue a lista e comece o primeiro item. Trabalhe 
pela lista até o almoço, e depois continue de onde parou e tente concluí-la. 

À medida que você completa cada item da lista, marque “FEITO”. Use letras 
maiúsculas. Esteja feliz. Ao fim do dia, olhe para sua lista de coisas FEITAS e sinta 
que você conquistou alguma coisa. Não apenas você sabia o que ia fazer nesse dia, 
mas agora você sabe que o fez. 

Se você não concluiu tudo, não se preocupe. Você sabia que não estaria certo 
em relação a quanto caberia em um dia de qualquer forma. Apenas mova os itens 
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incompletos de hoje (se ainda forem relevantes) para a lista de amanhã, e comece 
o processo de novo. É um processo estimulante. É rítmico. Isso permite que você 
divida seus dias e semanas em séries de pequenas vitórias, cada uma incentivando- 
lhe para a outra. Você descobrirá que isso não apenas lhe dá visibilidade para o que 
está conquistando, mas lhe dará, na verdade, mais feitios do que se você não estivesse 
olhando as coisas tão de perto. 

Uma vez estabelecido um ritmo de planos e ataques, você está pronto para co- 
meçar a pensar em termos de semanas e até mesmo meses. É claro, quanto mais 
comprido for o espaço de tempo para o qual você está planejando, maior o nível que 
seu planejamento deve ter. Pense nos planos diários e semanais como planos de ba- 
talhas táticas, com planos de trinta, sessenta, e noventa dias focando em objetivos 
mais estratégicos que você quer alcançar. 

O próprio ato de pensar sobre o que você quer alcançar em noventa dias é algo 
não natural desenvolvedores de software. 

Nós somos pessoas táticas. Forçar-se a imaginar um estado final para seu sis- 
tema, para o processo de sua equipe, ou de sua carreira depois de noventa dias vai 
trazer coisas à tona que você nunca esperaria. O campo, visto de cima, mostra-nos 
várias coisas diferentes do que a visão do chão. É difícil no começo, mas mantenha-se 
firme a isso. Como todas as boas habilidades, isso se torna mais fácil com a prática, 
e os benefícios serão visíveis tanto para você como para aqueles que trabalham com 
você (mesmo se eles não sabem o que você está fazendo). 


Relatórios de status podem ajudá-lo a se vender e mostrar resultados. 


Você deveria começar a comunicar seus planos para seus chefes. O melhor mo- 
mento para isso é depois de ter executado pelo menos um ciclo do plano. E — este 
é um ponto importante — comece a fazer isso antes de eles lhe pedirem. Nenhum 
chefe em sã consciência ficaria chateado ao receber um e-mail semanal sucinto de 
um funcionário, estabelecendo o que foi feito na semana anterior e o que está plane- 
jado para a próxima. Receber esse tipo de mensagem regular não solicitada é a paz 
de todo chefe. 

Comece comunicando-se semana por semana. Quando você estiver confortável 
com esse procedimento, comece a trabalhar em planos de trinta, sessenta e noventa 
dias. 

A longo prazo, concentre-se no progresso mais alto nível e impactante que você 
deseja aplicar em seus projetos ou nos sistemas que você mantém. Sempre estabeleça 
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esses planejamentos como propostas para seu chefe, e pega por feedback. Com o 
tempo, essas tentativas de antecipagäo väo requerer menos puxöes de orelha dos seus 
chefes, conforme vocé aprende quais itens geralmente náo precisam ser editados e 
quais sáo assuntos que precisam de mais atencáo. 

O fator mais crítico para se ter em mente com tudo que vai em um planejamento 
é que tudo deve ser contabilizado depois. Cada item deve estar ou visivelmente al- 
cangado, atrasado, removido, ou substituido. Nenhum item pode estar fora dessas 
categorias. Se itens aparecem em um plano, e nunca sáo mencionados de novo, as 
pessoas váo parar de confiar em seus planos, e vocé estará indo contra a eficácia do 
planejamento. Mesmo se o resultado é ruim, vocé também deve comunicá-lo. To- 
dos nós cometemos erros. O jeito de se diferenciar é tornar públicos seus erros e 
inabilidades, e pedir ajuda para resolvé-los. Seguir consistentemente as tarefas de 
um plano vai gerar a merecida impressáo de que nenhum trabalho importante está 
se perdendo no meio. 

Mantenha esse procedimento e de repente, aos olhos de seu chefe, vocé expós 
seu lado estratégico. Criar e executar planos demonstra que vocé náo é apenas um 
robó que digita códigos, mas que vocé é um líder. É esse tipo de produtividade 
independente que as empresas precisam conforme elas reduzem a sobrecarga. 

Um benefício final de comunicar seus planos é que seus comprometimentos ga- 
nham mais credibilidade. Se vocé disser que vocé vai fazer algo, e realmente o faz e 
o mostra pronto, vocé desenvolve a reputacáo de ser um cumpridor. Com credibi- 
lidade vem a influéncia. Imagine que vocé queira introduzir um novo processo, tal 
como uma prática de desenvolvimento ágil, em sua empresa, ou entáo vocé quer tra- 
zer uma nova tecnologia. Com sua habilidade comprovada de estabelecer e alcançar 
compromissos, väo conceder-lhe mais liberdade para tentar coisas novas. 

Em nosso centro de software de Bangalore, tinhamos uma equipe que trabalhou 
em turnos da noite por mais de um ano. Dos sete membros da equipe, dois estavam 
sempre no turno da noite. Eles revezavam semanalmente, de modo que toda terceira 
ou quarta semana, cada membro mudaria para o horário das 19h ás 3h da manhá. A 
equipe estava cada vez mais frustrada e esgotada. Mas a equipe estava atuando em 
um papel de apoio crucial, e os clientes internos que ficavam nos Estados Unidos 
estavam convictos de que náo conseguiriam continuar sem a ajuda em tempo real, 
ao vivo, do grupo de Bangalore. 

Entáo, a equipe formulou um plano de ataque. Eles olharam para seus vários 
processos de suporte e suas medidas associadas, e montaram um plano para tanto 
voltar para o turno de um dia quanto para fazer melhorias significantes para seus 
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clientes, simultaneamente. Como líder de operações ativas no centro de software, 
eu os ajudei a sofisticar o plano e estive presente (como apoio moral) na proposta 
formal que eles fizeram ao chefe dos Estados Unidos. 

Eles sabiam que isso seria um assunto delicado para o chefe, que teria que res- 
ponder aos seus clientes americanos pessoalmente. 

Naturalmente houve muita trepidação entre os membros da equipe conforme 
a reunião começou. Entretanto, o chefe da equipe ficou tão impressionado e feliz 
que imediatamente assinou a proposta, e a equipe pôde colocar seu plano em ação. 
Dentro de poucas semanas, a loucura tinha acabado e todo mundo estava de volta 
para o turno do dia. 

A solidez desse plano para, não apenas lidar com a mudança na carga horá- 
ria, mas também para as melhorias estratégicas na performance da equipe, inspi- 
rou grande confiança em seus chefes e, eventualmente, em seus clientes. O gerente 
da equipe usou o plano quando comunicou a mudança a seus clientes. E a equipe 
prosseguiu assim. Dentro de meses, estavam funcionando dentro de um novo ní- 
vel de eficiência. Desde então eles conquistaram tanta credibilidade e confiança que 
receberam mais e mais propriedade e independência em seus trabalhos. 

A equipe usava seu plano como uma resposta completa a um problema. Eles se 
dirigiam ao seu chefe não com reclamações, mas com propostas de soluções. 

Seus líderes querem que você tenha independência e propriedade. Fazer, execu- 
tar, e comunicar seus planos irá ajudá-lo a obter ambos. 


Falhar e copiar 


por Patrick Collison 

Larry Wall escreveu que as características de um ótimo programador são a pre- 
guiça, a impaciência e a arrogância. Eu não sei se isso é inato ou se pode ser adquirido 
com o tempo. De qualquer forma, não é fácil usar essa informação para se tornar um 
programador melhor. Então, em vez de olhar as características, devíamos olhar para 
as atividades que vão ajudar a trazer melhorias. 

Se eu tivesse que escolher duas, diria falhar e copiar. 

Eu falho mais do que a maioria dos programadores que conheço. Certamente, a 
maior parte dos meus projetos falha. Dentro do meu diretório Projects na minha 
máquina, eu tenho um monte de ideias interessantes negligenciadas, cada uma com a 
mesma probabilidade de dar certo quanto a de um peixe fugir do seu aquário. Assim 
como em famílias, projetos bem sucedidos são parecidos, enquanto cada projeto mal 
sucedido falha de um jeito próprio. 


141 


Casa do Código 





E apesar de ser quase um cliché dizer que a faléncia de uma empresa dá uma 
ótima experiência, eu não ouço a mesma ideia com relação à programação. 

(Eu sou bom nos dois, todavia, tive empresas que faliram também.) 

Falência comercial tende a construir um tipo de experiência bem direta. Você 
aprende a importância de guardar dinheiro, ou você se torna mais determinado. Mas, 
em se tratando de programação, não é muito a experiência de falir que é valiosa e 
que importa, mas sim o conhecimento adquirido enquanto se trabalha nos projetos 
que podem falhar. 

Quando comecei a programar, muito de meu tempo era gasto em tentativas fa- 
lhas de escrever todos os tipos de coisas incríveis: sistemas operacionais, sistemas 
de arquivos, máquinas virtuais, reimplementação de protocolo de rede, interpreta- 
dores e compiladores JIT. A maioria deles nunca funcionou direito, e aqueles que 
funcionaram eram mesmo assim muito ruins. É claro, mesmo ignorando os aspec- 
tos técnicos, a maior parte estava condenada desde o princípio. Eu não tenho certeza 
de qual fração de 1% é a taxa de sucesso para se criar um novo sistema operacional, 
mas é pequena. 

Ainda assim, para mim, esses projetos são a forma mais gostosa da programação. 
São problemas fundamentais de engenharia de software. É tudo questão de um perde 
e ganha entre espaço, velocidade, confiabilidade e complexidade, sem ter um código 
cheio de bugs em vista. 

Esses são os tipos de problemas nos quais você pode ficar enfiado durante meses e 
mesmo assim não conseguir sair com alguma coisa que funcione — como aconteceu 
comigo. 

Não sei exatamente por quê, mas as pessoas que estão aprendendo programação 
hoje não parecem muito ter esse tipo de experiência. 

Eu acho que isso pode ser, ao menos parcialmente, devido à ascensão de siste- 
mas web. Poucos dias atrás, uma pessoa da Hacker News perguntou se ainda existia 
alguém interessado em escrever software client-side. É um exagero, mas não está tão 
longe da verdade. E ei, software para web é mesmo bem legal. 

Do ponto de vista de um programador, contudo, essa mudança tem uma desvan- 
tagem. Apps web raramente envolvem duros desafios técnicos, até que você precise 
enfrentar os problemas de compatibilidade do Internet Explorer. 

Em outras palavras, a barreira de entrada para o fracasso é maior. Você tem que 
ser bem sucedido antes. 

Portanto, especialmente dado este movimento em direção aos sistemas web, eu 
penso que é importante procurar por projetos sujeitos a falhas. 
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E quanto a copiar? Para se tornar um melhor programador, qualquer pessoa lhe 
dirá que você deve ler códigos bons. Mesmo que eles presumidamente não queiram 
dizer isso literalmente (isso seria realmente chato), “ler” permanece sendo, no fundo, 
uma ideia errada: é passivo. Em vez disso, eu acho que você deve ativamente copiar, 
sem dó e sem ter vergonha disso. 

Isso se aplica a muitas coisas, é claro. Hunter S. Thompson não apenas lia bons 
livros; ele redigitava Hemingway e Fitzgerald. E os manuscritos mais velhos conhe- 
cidos do Bach eram transcrições que Bach fazia de trabalhos de outros organistas. 
Um dos casos mais famosos, talvez, seja o de Gates pegar programas em latas de lixo 
em Harvard. 

Não é muito difícil entender como isso ajuda. Copiar constrói memória muscu- 
lar. Você sente a nuance e a forma do original — o tipo de detalhe que seria perdido 
em uma leitura rápida. 

No caso de código, também há um benefício menos óbvio — mas significante. 
Copiar permite ir mais fundo com projetos que possam vir a falhar. Isso pode ser 
uma transcrição franca da, digamos, implementação de uma hash-table (o que tor- 
nou meu primeiro interpretador “menos pior”) ou um design que apenas inspirou e 
se moldou ao original (como, digamos, o Linux foi pelo Minix). 

Na melhor das hipóteses, isso leva a um tipo de ciclo virtuoso de falhar e copiar, 
que se torna um autoaprimoramento preguicoso. 

Você lida com algo duro, tropeça em algum problema insuperável, copia a solu- 
ção de outra pessoa e, ei, agora você sabe o que fazer, o que quer que seja. 

Nesse roubo irrestrito, à medida que você sinceramente absorve várias técnicas, 
você descobre como usá-las de uma nova maneira. Eu não sei ao certo o que Picasso 
quis dizer com “Bons artistas copiam, enquanto ótimos artistas roubam”. Talvez ele 
estava apenas sendo intencionalmente perverso, mas o significado inicial é o que eu 
sempre presumi. 

Programação é cheia de ideias estranhas. Usar nomes mais curtos e menos des- 
critivos frequentemente produz código que é mais legível no geral. As linguagens 
mais poderosas geralmente têm, de longe, menos conceitos do que as menos po- 
derosas. E falhar e copiar pode ser o melhor jeito de produzir um trabalho bem 
sucedido e original. 

Patrick Collison é um aluno do MIT 
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Percepcöes e perssepisöes 


É confortável bancar o idealista e fingir que vocé náo liga para o que as outras pessoas 
pensam de vocé. Vocé náo pode se deixar acreditar nisso. Vocé deve se preocupar 
com o que as outras pessoas pensam de você. Percepção é realidade. Supere isso. 

Você provavelmente conhece o clichê da velha questão filosófica, “Se uma árvore 
cai no meio da floresta mas ninguém está lá para ouvi-la cair, ela fez um som?” A 
correta resposta para isso é: “Quem se importa?” 

Quero dizer, a queda provavelmente produziu um som. Não é uma resposta 
muito interessante em um nível metafísico, mas ela provavelmente o fez. Mas, se 
ninguém a ouviu cair, o fato de ela ter produzido um som não importa. 

A mesma coisa vale para seu trabalho. Se você arrasa e ninguém está lá para ver, 
será que você arrasou mesmo? Quem se importa? Ninguém. 

Na subcultura burocrática de TI, na Índia, eu estava abismado com como eles 
realmente não conseguiam entender essa simples verdade. Quase todo mundo com 
quem lidei lá não entendia por que devia ser importante que seus chefes, por exem- 
plo, soubessem o que ele estava fazendo. Se você soubesse que você estava melho- 
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rando cada vez mais, isso se refletiria nos comentários de sua performance, em sua 
avaliacäo e em seu salário. Eles tinham se enganado ao pensar que a forma como os 
outros os viam era, de alguma forma, subserviente a verdade seja lá qual fosse. 

Essa coisa da verdade... o que éisso? O que é bom e o que é ruim em um sentido 
absoluto? 

A resposta é que náo há um bom ou ruim absoluto, ao menos náo em termos 
de julgar quem é melhor em um trabalho que exige criatividade e conhecimento. 
Como vocé define o que faz uma música ser boa? E quanto a um bom quadro? Vocé 
pode ter suas próprias definigöes, mas eu duvido que eu concordaria com elas. Sáo 
subjetivas. 


Avaliagöes de performance nunca säo objetivas. 


Os péssimos departamentos de recursos humanos de péssimas empresas giram 
suas engrenagens buscando modos objetivos de mensurar as pessoas que contratam. 
As vezes, eles nem implementam sistemas de avaliagäo “objetivos”. Todos os mem- 
bros da minha equipe na Índia achavam que eles deveriam ser medidos dessa forma. 

Náo existe maneira de medir objetivamente a qualidade de um trabalhador li- 
gado ao conhecimento, e também náo há como medir objetivamente a qualidade 
de seu trabalho. Vá em frente. Discorde. Agora pense em seu argumento por um 
instante. Percebe as falhas? 

Entáo, se a medida de sua eficácia em sua empresa (ou indústria, ou mercado de 
trabalho, o que for) é subjetiva, o que isso significa? Que vocé sempre será avaliado 
baseado na percepção que outra pessoa tem de você. O potencial de ser promovido 
ou de ter um aumento no salário — mesmo a decisão de se você deve continuar na 
folha de pagamento — depende completamente da percepção dos outros. 

Subjetividade, baseada em gosto pessoal, implica que você não pode contar que 
dois pareceres serão o mesmo. Pessoas diferentes se impressionam com diferentes 
fatores. Alguns podem gostar de uma estrutura rígida, enquanto outros preferem 
mais solta, com liberdade de criação. Alguns podem preferir se comunicar via e- 
mail e outros, pessoalmente, ou por telefone. Alguns chefes podem gostar que seus 
funcionários sejam mais agressivos, enquanto outros preferem que ajam como su- 
bordinados. Você diz “biscoito” — eu digo “bolacha”. 

Não se trata apenas de preferência pessoal. As pessoas interagem com você com 


diferentes funções e relacionamentos, e constroem suas percepções com base nas ca- 
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racterísticas mais importantes para fazer aquele relacionamento em particular fun- 
cionar bem. Se eu sou gerente de um projeto, a qualidade de seu código fonte é muito 
menos importante para mim do que a qualidade de nossa comunicagäo. Se eu sou 
um colega de programação, sua habilidade bruta e sua criatividade dirigem a per- 
cepção que tenho de você mais que, por exemplo, seu acompanhamento. Mas se eu 
sou seu chefe, a habilidade crua é fundamentalmente insignificante para mim, a não 
ser que você realmente faça algo com isso. 

Nós culturalmente nos treinamos para perceber que lidar com a percepção é, de 
certa forma, uma atividade suja e vergonhosa. Mas, como você pode ver, controlar 
a percepção é apenas prático. Quando você explicitamente nota so fatores que diri- 
gem as percepções que outras pessoas têm de você, você descobre com mais firmeza 
como deixar os clientes felizes. Você não vai impressionar seu cliente com suas habi- 
lidades de programação orientada a objeto. Você pode ser um gênio em design, mas 
se você não consegue se comunicar efetivamente e você não consegue completar seu 
trabalho a tempo, seus clientes pensarão que você é ruim. Não é culpa deles. Você é 
ruim. 

Percepções realmente importam. Elas o mantêm empregado (ou desempre- 
gado). Elas o levam à promoção ou o deixam preso no mesmo cargo por anos. Elas 
lhe dão aumento ou diminuição em seu salário. Quanto mais cedo você se superar e 
aprender a lidar com percepção, mais cedo você estará no caminho certo. 


Faça algo 


1) Percepções são conduzidas por diferentes fatores, dependendo de qual o público 
alvo. Sua mãe não se importa muito sobre quão bem você consegue programar 
sistemas orientados a objetos, mas seus colegas de equipe sim. 


Entender o que é importante em cada relacionamento é uma parte crucial para 
formar percepções verossímeis naqueles com quem você interage. Pense nos di- 
ferentes tipos de relacionamento que você geralmente tem com as pessoas do es- 
critório. Por exemplo, você provavelmente tem colegas que fazem o mesmo tipo 
de serviço que você. Você também provavelmente tem um chefe direto, e talvez 
você tenha um ou mais clientes e um gerente de projeto. 


Pegue esses grupos diferentes (ou quaisquer que se aplicarem, dada a estrutura 
de seu ambiente de trabalho), e os liste. Próximo a cada um, escreva quais dos 
seus atributos mais provavelmente vão conduzir a percepção daquele grupo sobre 
você. Aqui está um exemplo: 
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Condutores de percepcáo 


Colegas de 


equipe Habilidades técnicas, sociais e trabalho em equipe 


Foco no cliente, habilidades de comunicacáo, 


Clientes acompanhamento 





Pense um pouco sobre sua própria lista. Como vocé poderia mudar seu com- 
portamento com o resultado dessa lista? De que maneira vocé já vem ajustando 
seu foco conforme interage com cada grupo? E em que sentido vocé náo tem 
ajustado apropriadamente seu comportamento? 
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CAPÍTULO 34 


Guia de aventura 


Com o risco de afirmar o óbvio, o aspecto mais importante para colocar sua pala- 
vra para fora em seu ambiente de trabalho é sua habilidade de se comunicar. Já se 
foram os dias do hacker despenteado inclinado sobre seu terminal e escrevendo có- 
digos pela luz de seu monitor nas entranhas mais profundas do servidor. O grunhido 
monossilábico ocasional náo vai funcionar. 

Mesmo que a proposta seja perturbadora, ponha-se na mente de um chefe ou 
de um cliente (eu usarei apenas a palavra cliente neste capítulo para me referir a 
ambos). 

Eles sáo responsáveis por algo táo gravemente importante que, em último caso, 
precisam confiar em algum cara assustador de TI para a implementar algo. Eles fa- 
zem o que podem para ajudar a movimentar as coisas, mas no fim das contas eles es- 
tao a mercé desses programadores. Além disso, eles nao tém ideia de como controlá- 
los ou mesmo como se comunicar inteligentemente sobre o que é que estáo fazendo. 
Nessa situagäo, qual seria o atributo mais importante que eles estariam procurando 
em um membro da equipe? Eu aposto o preço deste livro que não era se eles tinham 
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memorizado os últimos design patterns ou quantas linguagens de programagäo eles 
sabiam. 

Eles estavam procurando por alguém que os deixassem confortáveis quanto ao pro- 
jeto no qual estáo trabalhando. 


Seus clientes tém medo de vocé. 


Esses gerentes e clientes estavam conversando sobre ter um pequeno segredi- 
nho: eles têm medo de você. E com uma boa razão. Você é esperto. Você fala uma 
linguagem oculta que eles não entendem. Você os faz sentir estúpidos com seus co- 
mentários sarcásticos (nos quais você talvez nem teve a intenção de ser sarcástico). 
E seu trabalho é frequentemente o último e mais importante pedágio entre a con- 
cepção de um projeto e seu nascimento. 

Sua função é ser o guia de aventura de seu cliente, através dos implacáveis ter- 
renos do mundo da tecnologia da informação. Você vai deixar seus clientes confor- 
táveis enquanto os guia em um lugar não familiar. Você os fará suspirar e os levará 
onde eles querem ir, enquanto evita as partes obscuras e decadentes que você encon- 
trou no passado. 

Pessoas que não programam são, na média, tão inteligente quanto os progra- 
madores. (Isso quer dizer que a maioria deles não é muito inteligente, mas poucos 
realmente são). Há grandes chances de seu cliente ser tão esperto quanto você, mas 
não saber como programar. Está tudo bem. Você provavelmente não sabe fazer o 
que ele, por sua vez, faz em seu dia a dia. Por isso há dois de vocês, e ambos estão 
sendo pagos para aparecer no trabalho. 

Eu mencionei um pouco sobre inteligência porque as pessoas da computação, 
com muita frequência, presumem que quem não sabe como operar um computador 
não é inteligente. Dizer isso tão explicitamente assim soa idiota, mas é a verdade de 
todos os preconceitos. Contudo, essa sensação é tão arraigada em tantos de nós que 
nem mesmo sabemos quando a sentimos. Tentar controlar isso explicitamente não 
funciona. 

Meu conselho é reverter o relacionamento. Em vez de se achar um gênio da 
computação, descendente do céu dos computadores para salvar seu pobre cliente do 
purgatório, vire a mesa ao contrário. Se você está, por exemplo, trabalhando em uma 
seguradora, pense em seus clientes como um especialista no assunto de seguros, dos 
quais você tem o que aprender para fazer seu serviço. 
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Tendo dito isso, vocé precisa estar ciente de que seus clientes podem precisar 
atenuar os tópicos técnicos um pouco quando vocés estiverem discutindo sobre as- 
suntos relacionados a software. Há um balanço delicado entre muito tecnólogo e 
muito ignorante. 

“Por que toda essa tarefa sobre como tratar seus clientes? Eu achei que nós íamos 
conversar sobre como fazer propaganda de mim mesmo.” Se vocé trabalha em uma 
típica empresa de TI, muito do orçamento que o mantém empregado vem de área de 
negócio. 

Quando estão sendo tomadas decisões sobre promoções e staff, o melhor advo- 
gado que você pode ter é um cliente que não quer ficar sem você. Do outro lado, 
imagine o impacto de um cliente que pensa que você é condescendente. Seu cliente 
representa a necessidade do negócio, e você é pago para fornecer o suprimento disso. 
Não se esqueça disso. 


Faça algo 


1) Olhe para si mesmo — você é aquele programador mau humorado e ogro que 
todo mundo teme? Você tem certeza? Eles têm medo de Ihe dizer? 


Vá ao seu e-mail e procure exemplos de e-mails que você enviou a colegas de 
trabalho menos técnicos, chefes e clientes. Conforme você lê, tente ver as coisas 
a partir do ponto de vista do destinatário. Se já passou algum tempo desde que 
você enviou as mensagens, você poderá se ver como um observador na terceira 
pessoa. 


Melhor ainda, mostre os e-mails para sua mãe. Conte para ela que alguém com 
quem você trabalha vai enviar as mensagens para um cliente, e pergunte a ela 
como essas mensagens fariam-na sentir. 


2) Pule a cerca — encontre uma oportunidade para ser jogado em uma situação em 
que você não é especialista e, portanto, depende daqueles que são. 


Se você tem dois pés esquerdos, imagine-se em um time de futebol. Se você tem 
dois polegares esquerdos, imagine que você é parte da Equipe Nacional de Tricô. 
Como você gostaria que seus colegas de equipe se comunicassem com você? 
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Eu iscrevu mto beim 


Os dias do programador ogro e monossilábico acabaram. Se as empresas querem ter 
dificuldades em se comunicar com seus programadores, eles os enviaráo para um 
outro continente e em um fuso horário diferente e se comunicaráo apenas via e-mail 
e telefone. 

Portanto, comunicação é importante. Na lista de tarefas que você tem que fazer 
para permanecer empregado, isso pode parecer meio artificial, bobo ou trivial. Tal- 
vez vocé se sinta como se tivesse voltado ás aulas do ensino médio. Tudo bem. Desta 
vez, vocé pode realmente prestar atencáo. 

Vamos passar pela mais chata primeiro: gramática e ortografia sáo importantes. 
Vocé provavelmente tem um diploma em um assunto avangado como engenharia ou 
ciéncia da computagäo, e aqui estou ensinando-o a soletrar. Coragem! 

Mas, pelo menos nos Estados Unidos, temos um problema. 

De acordo com uma reportagem da Comissáo Nacional de Escrita (http://www. 
writingcommission.org/report.html) , mais da metade das empresas entrevistadas 
levam em consideragäo as habilidades de escrita quando estáo tomando decisóes 


Casa do Código 





tanto para contratar como para promover. 40% dos entrevistados do setor de servigos 
disseram que um tergo ou menos de suas contratacóes correspondia ás habilidades 
de escrita desejadas. 

Quando vocé realmente dá um passo para trás e olha para o grande cenário, 
habilidades de escrita sáo necessárias e estáo em falta. 

Como você sabe, a força de trabalho mundial está se distribuindo globalmente. 
Conforme a tendéncia continua, vai chegar uma hora — para alguns, o momento é 
agora! — quando a maior parte da comunicacáo no local de trabalho será feita em 
forma escrita, seja por mensagem instantánea ou e-mail. 

Vocé escreverá muito. Se parte táo grande do seu trabalho envolverá escrever, 
é melhor você ser bom nisso. Mais do que nunca, as percepções sobre você serão 
formadas com base em sua habilidade de escrita. Você pode ser um ótimo progra- 
mador, mas se você não consegue se expressar em palavras, você não será tão eficaz 
em uma equipe distribuída. 

A habilidade de escrever cria tanto uma percepção superficial de você, como pos- 
sibilita uma real compreensão de como sua mente funciona. Se você não consegue 
organizar seus pensamentos em sua língua materna de modo que os outros consi- 
gam claramente os entender, como nós podemos esperar que você consiga fazer isso 
em uma linguagem de programação? A habilidade de formular uma ideia e guiar o 
leitor por um processo do pensamento até uma conclusão lógica não é muito dife- 
rente da habilidade de criar um design limpo e uma implementação de sistema que 
futuros mantenedores poderão entender. 

Não se trata de ser julgado. Se você possui membros de sua equipe em fusos 
horários diferentes em locais distantes, escrever pode ser o único jeito que você tem 
de explicar como você programou algo, ou em que seus colegas devem trabalhar. 


Você é o que você consegue explicar. 


Comunicação, especialmente por escrito, é o gargalo pelo qual todas as suas ma- 
ravilhosas ideias devem passar. Você é o que você consegue explicar. 


Faça algo 
1) Comece a manter um diário de desenvolvimento. Escreva um pouco em cada 
dia, explicando em que você tem trabalhado, justificando suas decisões de pro- 


gramação e examinando difíceis decisões técnicas e profissionais. Mesmo que 
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2) 


você seja seu primeiro (ou único — depende de você) público, preste atenção na 
qualidade de sua escrita e em sua habilidade de se expressar claramente. Ocasi- 
onalmente, releia registros antigos e os critique. Ajuste seus novos registros com 
base no que você gostou ou desgostou nos anteriores. Não apenas sua escrita vai 
melhorar, mas você pode também usar esse diário como uma forma de fortale- 
cer seu entendimento das decisões que você tomou, e como um lugar ao qual se 
referir quando precisar entender como e por que você fez tal coisa. 


Aprenda a digitar. Se você ainda não é um datilógrafo, faça um curso ou baixe 
algum programa para ensiná-lo. É mais provável que você se sinta confortável e 
natural em sua escrita se você está confortável com o jeito como você o faz. É 
claro, com todas as coisas que você terá que escrever, você pode já economizar 
tempo aprendendo a digitar rapidamente. 


155 


CAPÍTULO 36 


Estar presente 


Vocé possui a vantagem de estar frente a frente com seus líderes e seus clientes. Náo 
desperdice a oportunidade. 

Quando eu morava em Bangalore, como diretor técnico (CTO — Chief Techni- 
cal Officer) do nosso centro de desenvolvimento de software, eu tive a desagradável 
experiéncia de relatar ao gerente sobre quem eu náo apenas desgostava (e que náo 
gostava de mim), mas quem estava nos Estados Unidos. Tínhamos conversas tensas 
no telefone, tarde da noite ou logo pela manhá, que se tornavam cada vez mais frus- 
trantes por causa de ruídos de fundo ou porque a linha caía. Eu escrevia e-mails lon- 
gos e descritivos tentando ajudar a encurtar a distância e a diferença de fuso horário, 
mas era apenas ignorado. E se eu reclamasse sobre ser ignorado, eu seria criticado 
por escrever e-mails longos. Parecia uma situação sem saída. 

Minha empresa, na época, tinha um processo anual de revisão de performance, 
no qual os chefes listavam o desempenho de seus funcionários e suas (assim chama- 
das) necessidades de desenvolvimento. No topo da minha lista de necessidades de 
desenvolvimento estava algo chamado presença. 
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Mas presenga, nesse contexto, é uma palavra de cunho empresarial para descre- 
ver uma característica bem confusa sobre lideranga. Trata-se da qualidade imensu- 
rável de ter sua presença marcada — principalmente em situações face a face. Isso 
também inclui a qualidade igualmente imensurável de levar a si mesmo como um 
líder. 

Quando eu ficava sentado conversando sobre minha revisáo de performance (ao 
telefone) com minha amada chefe, eu colocava o telefone no mudo quando ela dizia 
“presença”. Eu nao queria que ela me ouvisse rindo. Eu ficava imaginando se ela 
podia ver a minha cara de metade careta, metade sorriso, que eu não conseguia tirar 
do rosto pelo resto da conversa. Ambos, ela e eu, sabíamos que o problema real era 
presenga na forma mais comum do termo: eu apenas náo estava nos Estados Unidos 
com todo mundo. 

A maioria de nós que só queria compartilhar o que pensávamos, náo gostava 
dessa chefe. Ela fez pouca coisa para impor respeito, entáo isso já era esperado. O 
padráo que apareceu foi que os únicos funcionários que tinham um relacionamento 
realmente negativo com ela eram os que náo estavam geograficamente no mesmo 
lugar que ela. 

Aqueles em outros países, tais como India, Hungria e a Grá Bretanha (em ordem 
decrescente) tinham relacionamentos tensos com ela, já que estávamos náo apenas 
separados fisicamente, mas tinhamos horários, infraestrutura, cultura e limites por 
causa do idioma. 

Parecia que, mesmo para as pessoas dos Estados Unidos que faziam tudo o que 
podiam para evitar essa chefe, a proximidade física e as conversas frente a frente 
ocasionais eram todo o necessário para deixá-la confortável. E, é claro, o fenómeno 
de “o que os olhos não veem, o coração não sente” era rapidamente validado quando 
eu colocava meus pés na Índia. 

Além de apenas contar uma história sobre uma gerente ruim, vocé pode apren- 
der algo mais dessa experiéncia. A proximidade física é uma vantagem no lugar de 
trabalho. 

Pense sobre a última vez que um parente ou um amigo, que náo era da área da 
computação, pediu-lhe ajuda com um problema do computador. Você tenta ajudar 
pelo telefone, e se eles não estão entendendo, você fica cada vez mais agitado. Se 
você pudesse mostrar para eles... Em contraste, a comunicação cara a cara é in- 
crivelmente eficaz. Você pode ouvir o outro lado mais claramente. Você pode usar 
de expressões visuais para se fazer entender, seja com gestos ou desenhos ou lousas. 
E todos nós expressamos implicitamente bastante conteúdo em nossas expressões 


158 


Casa do Código Capítulo 36. Estar presente 





faciais, mesmo sem perceber isso conscientemente. 

Nós náo apenas vemos mais produtividade e uma comunicagäo mais aprimorada 
por meio de interação cara a cara, mas também formamos laços pessoais mais fir- 
mes. Leva muito mais tempo criar algo que vocé chamaria de amizade se vocé nunca 
encontra a pessoa frente a frente. Quinze anos atrás, isso era inédito para nós. Hoje 
em dia, com a ubiquidade da internet, é menos comum do que amizades tradicionais 
cara a cara. Por muitas das mesmas razöes pelas quais trabalhamos com menos efi- 
ciéncia via telefone, e-mail e chat, nós também somos menos eficientes em construir 
um relacionamento dessa forma. Adicione a isso o desconforto da artificialidade de 
um e-mail ou de uma conversa em chat (algo de que a próxima geracáo provavel- 
mente náo vai se lembrar), e, na maioria dos casos, o relacionamento erguido em 
um ambiente de trabalho remoto vai permanecer estritamente centrado em cumprir 
tarefas. 

Um forte relacionamento de equipe, com comunicagäo eficaz e em banda larga, 
favorece na rapidez da entrega do software. Na maior parte dos ambientes, decisóes 
importantes sobre o projeto sáo feitas pessoalmente, nos intervalos para o café, e 
conversas paralelas. Essas são observações bastante óbvias, e a vantagem que a pes- 
soa tem em participar disso também é bastante óbvio. O que não é tão óbvio — 
especialmente para nós, geeks — é a importância de ser visto. 

Eu nunca entrei em um banco. Eu faço todas as tarefas bancárias ou online ou 
em caixas eletrônicos. Meus avós são diferentes. Eles fazem tudo o que precisam 
dentro do banco, conversando com pessoas reais. Eles nem gostam de conversar 
sobre negócios por telefone. Não é confortável para eles. Eles também conhecem as 
pessoas do armazém que frequentam. Eles vão e voltam várias vezes e conversam na 
saída. Eles não pensam em mudar de armazém (ou de banco), porque essa escolha 
é muito mais do que algo de peso pragmático de conveniência e custo. É pessoal. 

Enquanto não existirem robôs ou programas de computador para tratarem de 
nossas avaliações de performance, todos os negócios continuarão sendo pessoais. 
Nós, pessoas, gostamos de interagir com outras pessoas pessoalmente. Alguns de 
nós, de qualquer maneira. 

O modo de trabalho natural de uma pessoa da computação é se enfiar em um 
cubículo, colocar seus fones de ouvido, e entrar “no clima” até a hora de comer. Dou- 
glas Coupland, em seu livro Microserfs [1], conta a agradável história de uma equipe 
que tinha que comprar comidas achatadas para poder passar debaixo da porta do 
escritório de um programador em uma missão. Esse tipo de isolamento focado se 
tornou parte da cultura e do folclore da indústria de software. 
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Infelizmente para a sua carreira, isso é ruim para o mercado. Se vocé está tran- 
cado em um escritório, acessivel apenas por telefone (se vocé atender) ou e-mail, e 
talvez até trabalhando todas as horas da madrugada e dormindo tarde, como con- 
sequéncia, náo existe diferenga entre vocé estar no mesmo local que seus chefes e 
clientes, ou estar no offshore. Vocé está perdendo uma grande oportunidade de se 
tornar uma figura memorável em sua empresa. Lembre-se, vocé precisa tornar as 
coisas pessoais, e para isso, vocé precisa lembrar da tendéncia humana natural de 
querer trabalhar com outros seres humanos — náo por mensagem de voz, e-mail, 
ou mensagens instantáneas, mas pessoas reais. 


Aprenda sobre seus colegas. 


No atual ambiente distribuído, você pode pensar que, embora esteja no mesmo 
país que as pessoas com quem vocé trabalha, vocés náo estáo no mesmo estado ou na 
mesma cidade. Viagens regulares para ter reunióes pessoalmente sáo ótimas nessas 
situagöes se isso for prático para vocé e sua empresa. Mas a melhor coisa que vocé 
pode fazer é pegar o telefone e ligar para seus chefes e colegas. Náo use microfo- 
nes, e náo dependa de reunióes agendadas. Vocé precisa tentar simular o tipo casual 
das conversas dos intervalos para o café que vocé teria se morasse ou trabalhasse no 
mesmo lugar; portanto, separe um tempo para conversas (aparentemente) espontá- 
neas. Na ocasiáo, espere a oportunidade de tornar a conversa pessoal. Deixe que 
o “Como vai hoje?” siga para o “O que você geralmente faz nos finais de semana?” 
Tente aprender de verdade sobre as pessoas com quem vocé trabalha. Náo apenas 
isso o firma mais em sua empresa, como também é uma forma mais enriquecedora 
de viver. 


Faca algo 


1) Na próxima semana, pegue um dia para se forgar (com razáo) a náo mandar ne- 
nhum e-mail. Toda vez em que vocé iria, normalmente, enviar um e-mail, ou 
telefone para a pessoa ou, melhor ainda, vá até o escritório e converse com ela 
pessoalmente. 


2) Faca uma lista de colegas, chefes e clientes com quem vocé nao conversa o sufi- 
ciente. Coloque compromissos recorrentes em sua agenda para ligar e falar com 
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eles (ou pelo telefone, ou pessoalmente). Torne as conversas curtas mas signifi- 
cantes. Use-as para falar de coisas relacionadas ao trabalho e também para sim- 
plesmente estabelecer um contato humano. 
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CAPÍTULO 37 


Fale com propriedade 


Todos os meus jovens sobrinhos usam o computador regularmente. Eles sáo, rela- 
tivamente falando, bons entendedores de computador. Eles se comunicam com os 
amigos pelo mundo afora. Sentem-se completamente confortáveis com mensagens 
instantáneas, e-mail, baixar coisas da internet, e, é claro, tornarem-se públicos e to- 
das as coisas que vocé faria se fosse um aluno do ensino médio. 

Mas se eu fosse me exibir para eles, dizendo que meu novo computador tem um 
disco rígido de 10.000 RPM Serial ATA, eles podem, na melhor das hipóteses, tentar 
adolescentemente fingir um entusiasmo. Eles também ficariam pouco interessados 
se eu Ihes dissesse que tenho vários gigabytes de RAM e um GPU mais rápido do 
que os CPUs nos sistemas que usei apenas cinco anos atrás. 

Contudo, se eu Ihes dissesse que eles podem rodar o mais novo jogo de tiros em 
primeira pessoa, em alta resolução sem que a aparência visual do jogo fique pipo- 
cando, eles se sentariam e me escutariam. 

Gigahertz e rotações por minuto não são interessantes para a maioria dos meni- 
nos de 14 anos. Jogos de computador, sim. 
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Pessoas de negócio náo estáo táo interessados em gigahertz e RPM, tampouco. 
Eles gostam quando suas aplicagöes sáo rápidas, porque náo tém que esperar en- 
quanto estáo no telefone com um cliente, ou enquanto tentam fechar as contas do 
trimestre. 

Mas eles náo ligam para quantos pedidos por segundo o servidor de sua nova 
aplicação customizada pode atender. 

Os negócios e aqueles que lidam com ele estão interessados nos resultados. Por- 
tanto, promover suas realizações em qualquer outra língua que não a linguagem de 
negócio é ineficaz. 


Promova suas realizações na linguagem do seu negócio. 


Você não faria uma propaganda de um produto destinado ao público ameri- 
cano em alemão. Uma empresa de refrigerantes não tentaria vender uma bebida 
baseando-se na quantidade de corante nº8 que ela contém. O senso comum ensina 
que, para vender um produto para um determinado público alvo, você deve se di- 
rigir a essa audiência em uma linguagem que eles podem tanto entender como se 
referirem a ela. 

Como um desenvolvedor de softwares, isso significa esboçar suas realizações 
dentro do contexto da empresa para a qual você trabalha. Claro que você o fez, mas 
o que foi isso? Por que isso importava? Por que isso foi tão chamado de realização, 
e não apenas uma perda de tempo? 

Meu palpite é que se fosse para você pensar nas conquistas do último mês, você 
talvez não consiga articular a resposta de por que elas eram tarefas úteis para se 
fazer. Obviamente, mandaram-lhe realizá-las, mas quais benefícios elas agregaram 
ao negócio? 

Na General Electric, há uma lenda urbana de que o CEO original Jack Welch 
gostava de entrar em um elevador de um dos prédios da GE com um funcionário 
aleatório que tenha subido no elevador com ele. Ele se dirigia ao já amedrontado 
subalterno com a pergunta “Em que você está trabalhando?” para então perguntar 
(e é aqui que está a alfinetada) “Qual é o benefício disso?” A moral da história é que 
você deve sempre ter um discurso de elevador pronto, só para garantir. 

O que você diria se seu CEO Ihe fizesse a mesma pergunta, do nada? Mesmo 
tendo alguns minutos para se preparar, será que você conseguiria explicar o benefício 


das tarefas que você está realizando ou que recentemente concluiu? Você conseguiria 
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se expressar em palavras de modo que um alto executivo totalmente náo técnico 
pudesse náo apenas entender, mas também apreciar? 


Faca algo 


1) Faga uma lista de suas últimas realizacóes. Escreva o beneficio de negócio para 
cada uma. Se há conquistas para as quais vocé náo consegue escrever um benefí- 
cio, pergunte ao seu chefe ou a um conhecido confiável como eles enquadrariam 
o benefício. 


2) Faça seu discurso de elevador e decore-o. 
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CAPÍTULO 38 


Mude o mundo 


A pior coisa que alguém de seu trabalho pode perguntar sobre vocé é “O que ele/ela 
faz?” Ter de fazer essa pergunta significa que eles náo sabem o que vocé já fez. 

É triste, mas eu náo sei o que fazia a maioria das pessoas com quem trabalhei 
em uma grande empresa de TI. Simplesmente náo se pensa assim. Eles váo ao tra- 
balho, cumprem seus compromissos e voltam para casa. Náo há nenhum impacto 
marcante deixado por eles, que não seja o pedaço de código, documentos e e-mails 
que deixaram no histórico. 

Isso é o que acontece quando você vai trabalhar sem uma missão. Você apenas 
fica sentado, esperando que lhe digam o que fazer. E, quando você realiza a tarefa 
mandada, as únicas pessoas que saberão o que você fez são aquelas que o requisita- 
ram. Tudo bem se você quiser trabalhar seguindo a lógica de varejo ou mesmo se 
você quiser ser um programador offshore. 


Tenha uma missão. Assegure-se de que os outros saibam disso. 
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Porém, se vocé quer ser um desenvolvedor de software em um país de alto custo, 
você precisa ir ao trabalho com uma missão. Você precisa fazer a mudança, mas não 
mudar a si mesmo ou seu trabalho (que é dado). Você precisa efetuar mudanças 
visíveis através de sua equipe, da organização, da empresa. 

A mudança pode ser pequena. Você pode ter a chave do teste de unidade, ditando 
práticas de testes para todos os programadores de sua empresa. Ou pode ser algo 
maior, com a introdução radical de uma nova tecnologia, que levará a sistemas mais 
baratos e feitos mais rápido. 

Você faz essas coisas porque você é internamente guiado para fazê-las. Você 
não pode se afastar e assistir às pessoas fazerem coisas erradas. Você sabe que tudo 
poderia ser melhor, então você deve mudá-las. 

É claro, se você quer mudar o mundo, está ao mesmo tempo fadado a deixar 
algumas pessoas bravas. Tudo bem, contanto que suas intenções estejam certas. Não 
seja um idiota a respeito disso, mas também não precisa andar na ponta dos pés se 
fazendo de conservador sempre. 

Se você realmente acabar eliminando algumas pessoas, poderá, pelo menos, se 
sentir confortável pelo fato de que não vão mais perguntar “O que você faz?” 

Se você não sabe qual é sua cruzada, provavelmente não possui uma. Se ainda 
não está ativamente tentando deixar sua marca, você provavelmente não está con- 
seguindo. 


Faça algo 


1) Catalogue as jornadas que você pessoalmente testemunhou em seu ambiente de 
trabalho. Pense nas pessoas com quem você trabalhou, que agiam como se ti- 
vessem uma missão. Pense nas pessoas mais focadas e eficazes de sua empresa. 
Quais eram suas missões? 


Você pode pensar em alguma delas que tenha sido inapropriada? Qual o limite 
entre foco e obsessão? Você já viu alguém passar desse limite? 
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CAPÍTULO 39 


Faca sua voz ser ouvida 


As ideias que exploramos até aqui foram razoavelmente conservadoras e focadas em 
ser reconhecido pelo que vocé faz em seu trabalho. Se vocé quer ser percebido, pro- 
movido, ou mesmo ficar empregado em sua empresa atual, os tópicos nos quais to- 
camos seráo críticos. 

Mas que chato! 

O mundo está mudando. Se vocé quer garantir sua passagem, é preciso pensar 
mais alto do que os trabalhadores de TI do ano passado. Enquanto progredir de um 
nível 23 para o 24 na programação possa realmente ser seu objetivo de carreira a 
curto prazo, sendo um programador hoje, vocé deve pensar além da próxima pro- 
moção ou além até do seu emprego atual. 

Observe-se mais do alto. Não se defina como um programador de uma empresa 
específica — afinal, é provável que você não fique no mesmo lugar para sempre — 
mas como um membro participante de uma companhia. Você é um artesão ou um 
artista. Você tem algo a compartilhar além do aplicativo de relatório de despesas que 
você está desenvolvendo para o departamento de recursos humanos, ou os erros que 
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vocé corrigiu no sistema de testes de sua empresa. 

Empresas querem contratar especialistas. Enquanto um currículo com uma só- 
lida lista de projetos é um bom modo de demonstrar experiéncia, nada é melhor, 
em uma entrevista de emprego, do que o entrevistador já ter ouvido falar de vocé. 
É especialmente bom se eles já ouviram falar de vocé porque leram seus artigos ou 
livros, ou assistiram a uma palestra sua em um congresso. Vocé náo ia querer con- 
tratar a pessoa que “escreveu o livro” sobre a tecnologia ou metodologia que vocé 
está tentando implantar? 

Durante o tempo em que eu era saxofonista, eu tocava bastante nos clubes perto 
da rua Memphis’s Beale. Conforme eu comecei a me entrar na área da computação, 
eu percebi várias coincidências entre o modo como você precisa promover seu nome 
na indústria música e na computacáo. Quando eu era um músico tentando achar 
emprego, as seguintes propriedades eram válidas: 


e (Este é o mais importante) O melhor saxofonista nem sempre é contratado. 


e Com quem você tocou é, pelo menos, um dado tão importante como quão 
bem você toca; músicos são bons por associação. 


e As vezes, os melhores músicos são deixados para trás porque todo mundo pre- 
sume que eles não estarão disponíveis, porque estão muito intimidados para 
perguntar. 


e Música funciona via efeito de rede. Se sua rede social e musical termina antes 
de alcançar alguém, não é provável que você seja requisitado para tocar com 
aquela pessoa, até que algum intermediário faça a conexão. 


A indústria da computação é do mesmo jeito. Não existe um sistema objetivo 
para avaliar e empregar desenvolvedores de software. Ser bom é importante, mas 
não o leva até o fim. Nosso meio, como o musical, é uma grande, complexa rede de 
pessoas conectadas com outras. Quanto mais ligações você tem, maiores são suas 
chances de se conectar com o emprego perfeito ou de despontar em uma carreira. 
Limitar-se à empresa para a qual trabalha estabelece sérios limites no número de 
conexões que você pode formar. 

Qual a melhor maneira, senão fazer publicações e falar em público, para que seu 
nome seja propagado e sua voz se faça ouvida? Então, como você deixa de ser um 
programador Zé Ninguém para ser um autor publicado e um palestrante público? 
Comece na web. 
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Primeiro, leia blogs. Aprenda mais sobre a organização dos blogs e procure se 
tornar um membro. Se vocé náo sabe o que ler, pense em alguns autores dos seus 
livros técnicos favoritos e pesquise na web. Vocé provavelmente descobrirá que eles 
tém um blog. Assine o feed e também os das pessoas ás quais eles linkam. Com o 
tempo, sua lista de feeds vai crescer ao passo que vocé lé e encontra links de outros 
blogs. 

Agora abra seu próprio blog. Há vários servicos gratuitos disponiveis para se 
criar um blog. É extremamente simples. Comece escrevendo (e linkando) histórias 
que vocé acha interessante. Conforme escreve, vocé descobrirá que o universo dos 
blogs é por si só uma rede social — um microcosmo da rede de carreira que vocé 
está comecando a construir. Seus pensamentos váo eventualmente aparecer nos fe- 
eds agregados e de outros que curtem suas postagens, que escreveráo sobre isso e 
compartilharáo suas ideias. 

O blog é um campo de treinamento. Escreva na internet como se vocé estivesse 
escrevendo em uma coluna de sua revista preferida. Pratique a arte de escrever. Suas 
habilidades vão crescer, e você vai ganhar mais confiança. 

Seus posts também vão dar exemplos de trabalho que você pode usar no próximo 
passo. Agora que você está escrevendo em seu próprio ambiente, você pode também 
enviar seus tópicos para comunidades, revistas ou até livros. Com um portfólio de 
sua habilidade de escrita disponível na internet, você terá bastantes exemplos de ma- 
teriais para incluir em um artigo ou em uma proposta de livro. Publique, e sua rede 
crescerá. Quanto mais textos, você terá mais oportunidades de escrever. E tudo isso 
leva à oportunidade de palestrar em conferências. 

Assim como nós facilmente começamos na internet nossos empreendimentos 
de escrita, você pode começar sua carreira de palestrante em seus encontros de de- 
senvolvedores locais. Se você é alguém de .NET, prepare uma apresentação para o 
grupo local de desenvolvimento da Microsoft. Se você é um programador Linux, 
converse com o grupo de usuários de Linux. A prática leva à perfeição, no que tange 
aos discursos. Assegure-se de dedicar muita reflexão quando estiver preparando sua 
palestra. Não seja superficial. Mesmo que você esteja palestrando para apenas um 
pequeno grupo de pessoas em sua cidade natal, é lá onde você vive e trabalha. Um 
trabalho realmente bem feito, eventualmente vai ser recompensado. Você desco- 
brirá que, se você der a quantidade certa de atenção, localmente, essas pequenas pa- 
lestras não serão diferentes das conferências nos congressos das grandes indústrias. 
Estas são, obviamente, o próximo passo lógico. 


Com todas essas formas de levar seu nome e sua voz para fora, a dica mais crucial 
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de todas é comegar táo logo quanto vocé achar que está pronto. A maioria das pessoas 


se vende mais barato do que poderia. 


Vocé tem algo a ensinar. Vocé nunca vai se sentir 100% pronto, entáo talvez vocé 


deva começar agora. 


Faca algo 


1) 
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Se vocé ainda náo tem um blog, crie um agora mesmo. Vá a um dos vários sites 
de hospedagem grátis e monte um. 


Agora crie um arquivo de texto em seu computador. Nele, faça uma lista de pos- 
siveis tópicos para seu blog. Esses seráo futuros artigos que vocé irá escrever. Náo 
se limite a ideias épicas. Mire em ideias sobre as quais vocé pode escrever em dez 
a vinte minutos. Pare quando a lista tiver dez itens (ao menos que vocé esteja 
inspirado — continue). 


Salve o arquivo mas deixe-o aberto. Se vocé reiniciar, abra novamente o arquivo. 
Vocé tem trés semanas. Cada dia, escolha um item da lista e escreva um artigo. 
Náo pense muito sobre isso. Apenas escreva e publique. Nos artigos, coloque 
links para outros blogs com artigos relacionados. Conforme vocé lé a lista para 
escolher o tópico do dia, sinta-se á vontade para acrescentar ideias no arquivo. 
Depois dessas trés semanas, escolha seus dois artigos favoritos e envie-os a sites 
novos moderados por usuários, como o Digg e o Reddit. 


Se vocé ainda tem ideias em sua lista, continue a escrever. 


CAPÍTULO 40 


Construa sua marca 


Construção de marca tem duas partes: realmente fazer sua marca, de modo que as 
pessoas a reconheçam, e ter certeza de que aquela marca é associada a traços positi- 
vos. Reconhecimento e respeito. 

Hoje, quando vemos uma suástica, pensamos no Hitler e na Alemanha nazista. 
Do ponto de vista de construção de marca, aquilo foi muito bom para os nazistas. 
Eles conquistaram a primeira parte de construção de marca: conscientização. Mas 
qualquer um que seja mentalmente são tem uma associação extremamente negativa 
com qualquer coisa relacionada ao holocausto. Assim, os nazistas, em última aná- 
lise, falharam miseravelmente na parte de fazer associações positivas. De fato, Hitler 
roubou a suástica dos hindus, cometendo o crime que todas as empresas sérias lutam 
para não cometer. Para os hindus, que reivindicam a suástica original (ou swasti), é 
um símbolo auspicioso de bem estar. Mas agora, pelo ocidente esse ícone espiritual 
foi difamado. Muito reconhecimento e pouco respeito. 

No lado oposto, está Charlie Wood. Ele é um cantor e compositor incrível, além 
de tocar o órgão B3 da Hammond em Memphis, Tennessee. Ele toca cinco noites por 
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semana em um clube na rua Beale. Todo mundo que o conhece ou ouviu falar dele 
sabe como ele é brilhante. Todos o admiram. Ele é o mais talentoso que vocé pode 
ser em se tratando de música R&B. 

Mas relativamente ninguém sabe quem ele &. Nenhum reconhecimento e muito 
respeito. 


O que vocé quer é tanto reconhecimento quanto respeito. Seu nome é sua marca. 


Seu nome é sua marca. 


Toda esta parte do livro é sobre como conseguir ambos. Aqui mesmo neste pará- 
grafo, o que você deve entender é que a combinação das duas coisas é um patrimônio 
que vale a pena construir e proteger. Diferente de um grande e assustado departa- 
mento de marketing corporativo, que processa crianças da faculdade por sites que 
se apropriam indevidamente de alguma imagem ou frase, você não precisa gastar 
muito tempo protegendo sua marca de outras pessoas. A força mais potencialmente 
destrutiva para sua marca é você mesmo. 

Não enfraqueça aquilo que você representa. Tenha cuidado com os lugares onde 
seu nome aparece. Não realize projetos ruins ou não envie péssimos e-mails para 
grupos grandes (nem faça posts ruins no blog para que toda a internet leia). Não seja 
um idiota. Ninguém gosta de um idiota, mesmo se eles, de alguma forma, merecem 
ser um idiota. 


O Google nunca esquece. 


Sobretudo, lembre-se de que as coisas que você escolheu fazer e às quais se asso- 
ciou, terão um impacto duradouro no significado que seu nome tem para as pessoas. 
Agora que muitas de nossas interações se dão via internet ou fóruns públicos, sites 
e listas de e-mails, muitas de nossas ações são de registro público, armazenadas em 
cache, indexadas e pesquisáveis — para sempre. 

Você pode esquecer, mas o Google não. 

Proteja sua marca com toda sua força. Defenda-a de si mesmo. É tudo que você 
tem. 
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Faca algo 


1) Pesquise seu nome no Google — digite seu nome no Google entre aspas. Veja as 
primeiras quatro páginas de resultados (sáo realmente quatro páginas de resul- 
tados?). O que alguém poderia deduzir de vocé depois de seguir apenas os links 
dessas quatro páginas? Vocé está bem representado nelas? Essa imagem que essas 


páginas constroem lhe agrada? 


Faça a mesma pesquisa de novo, mas desta vez preste atenção a conversas de fó- 
runs e listas de e-mails. Vocé é um idiota? 
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CAPÍTULO 41 


Lance seu código 


Imagine como seria mais fácil arranjar um emprego se houvesse empresas que já se 
utilizassem de um software que vocé escreveu. Vocé poderia dizer “Oh, vocés estáo 
usando Nifty ++?” Eu posso ajudá-los — fui eu que inventei”. Isso seria diferente. 
Entrevistadores e gerentes de contratação se lembrariam de você. É isso que você 
quer. 

Apenas uma década atrás, isso parecia uma boa ideia, mas náo havia muitas 
oportunidades para se fazer isso. Vocé tinha que ter trabalhado para um fornece- 
dor de software comercial primeiro, e suas credenciais seriam relacionadas aos pro- 
dutos que vocé ajudou a desenvolver enquanto trabalhava para eles. Mas as coisas 
mudaram. Vocé náo tem mais que trabalhar para Os Grandes para desenvolver um 
software popular, com marca própria. 

Agora há uma outra saída: open source. Software open source atingiu o mains- 
tream. Conforme empresas de TI começam novos projetos, o velho debate mudou 
de construir vs. comprar para construir vs. comprar vs. baixar. Senão aplicações in- 
teiras, frameworks variando de pequenas bibliotecas a containers de aplicacóes estáo 
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sendo lançados sob licença open source e estão, de fato, se tornando padrões. 

E as pessoas que estão desenvolvendo este software, na maior parte, são pessoas 
como você. São pessoas sentadas em suas casas de tarde e aos fins de semana, labu- 
tando em softwares como um trabalho apaixonado. É claro, existem alguns recursos 
vindos de empresas para criar e dar suporte aos produtos open source. Mas a maioria 
dos desenvolvimentos open source é feita por programadores independentes, como 
um hobby. 


Qualquer um pode usar Rails. Poucos podem se dizer contribuinte do Rails. 


Embora muitos desses desenvolvedores estejam apenas se divertindo e se expres- 
sando, há alguns incentivos reais aí. Eles estão subindo na cadeia social de uma co- 
munidade. Estão construindo nome para si mesmos. Estão construindo uma repu- 
tação na indústria. Eles talvez não o estejam fazendo de propósito, mas estão fazendo 
marketing de si próprios no processo. 

Além de construir um nome para si mesmo, contribuir com software open source 
mostra que você é apaixonado pela sua área. Mesmo se uma empresa não usou ou 
ouviu falar de seu software, o fato de você tê-lo criado e lançado já é um diferencial. 
Pense desta forma: se você estivesse querendo contratar um desenvolvedor, você 
preferiria alguém que se dedica apenas em suas horas de trabalho e depois vai para 
casa e assiste à TV? Ou você iria preferir alguém que tem tanta paixão pelo que faz 
que se supera e até faz horas extras programando em finais de semana? 

Contribuições open source demonstram habilidade. Se você está produzindo 
código real e contribuindo para um projeto real, isso é muito melhor em seu currí- 
culo do que apenas dizer que você conhece a tecnologia. Qualquer um pode escre- 
ver Rails ou Nant em seu currículo. Muitos poucos podem escrever contribuinte do 
Rails ou commiter do Nant. 

Liderar um projeto open source pode demonstrar muito mais do que competên- 
cia técnica. São necessárias habilidades em liderança, gerenciamento de releases, do- 
cumentação, e suporte a produtos e comunidades para promover uma comunidade 
em torno de seus esforços. E se você fizer essas coisas com sucesso — em seu tempo 
livre, como um hobby — você será incrivelmente diferente da maioria de pessoas 
competindo pelos mesmos cargos. A maior parte das empresas não pode pagar seus 
programadores para fazer todas essas coisas e bem feitas. A maioria não consegue 
nem pagar seus desenvolvedores para fazer algumas dessas coisas bem. Mostrar que 
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vocé náo apenas pode fazé-las, mas que vocé se preocupa o suficiente para fazé-las 
gratuitamente, demonstra um surpreendente poder de iniciativa. 

Se vocé cria algo realmente útil, vocé pode até terminar famoso. Vocé pode ser fa- 
moso em um pequeno campo técnico — talvez famoso entre desenvolvedores Rails, 
por exemplo. Ou, se vocé tiver sorte, poderia ser realmente famoso mesmo fora da 
comunidade geek como Linus Torvalds ou... bem, como Linus. Mesmo se vocé náo 
é tao famoso, lançar seu código vai, definitivamente, torná-lo mais famoso. Se fama 
significa que muitas pessoas sabem quem você é, então ter mais uma pessoa que 
saiba de você o torna mais famoso. E a comunidade open source é uma rede mun- 
dial de pessoas que, pesquisando códigos na internet, podem encontrar seu software, 
instalá-lo e usá-lo. Ao fazer isso, eles o conhecerão, e, conforme seu software se es- 
palha, seu nome e sua reputação também crescerão. É disso que se trata o marketing. 
É o que você quer. 


Faça algo 


1) Stuart Halloway (http://thinkrelevance.com) tem um workshop feito em congres- 
sos que chama de “Refactotum”. Se você tiver a chance de participar, eu realmente 
o recomendo, mas a essência é o seguinte: 


Pegue uma parte de um software open source com testes de unidade. Rode os 
testes por um analisador de cobertura de código. Encontre a parte menos testada 
do sistema e escreva testes para melhorar a cobertura daquele código. Códigos 
não testados geralmente são códigos não testáveis. Refatore para torná-lo mais 
testável. Envie um patch com a sua alteração. 


O legal é que isso é mensurável e pode ser feito rapidamente. Não há desculpas 
para não tentar. 
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CAPÍTULO 42 


Seja marcante 


O currículo tradicional de marketing se refere aos quatro P: produto, preço, promo- 
cáo e praca (product, price, promotion and placement). A ideia é que, se vocé cobrir 
todas essas quatro categorias, vocé terá um plano de marketing completo, sendo que 
as quatro recebem o mesmo peso. 

Mas qual o objetivo do marketing? Seu propósito é criar conexáo entre os pro- 
dutores e consumidores de um produto ou um serviço. Esta ligação começa com a 
consciéncia sobre um produto. O mecanismo tradicional de criar consciéncia é via 
promoções, incluindo propagandas, postagens, e seminários educacionais. 

Recentemente, o mundo do marketing tem voltado sua atenção para o que é co- 
loquialmente chamado de marketing viral. Isso acontece quando a ideia é marcante 
o suficiente para os consumidores a espalharem uns aos outros. Ela propaga como 
um vírus, sendo que cada consumidor infectado potencialmente pode infectar mui- 
tos outros. 

Marketing viral não é preferido apenas porque é caro enviar postagens ou com- 
prar um tempo de propaganda na televisão. Sim, porque os consumidores confiam 
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mais em seus amigos do que em um comercial da TV ou um spam. Eles sáo mais 
propensos a comprar algo sobre o que ouviram falar de seus colegas de trabalho do 
que algo que viram em um anúncio no meio do jornal de domingo. 

Em seu livro Purple Cow [4] o mestre em marketing Seth Godin faz a öbvia aná- 
lise de que a melhor maneira de fazer um consumidor notar um produto é fazé-lo 
marcante. Godin vai mais longe e afirma que os quatro P sáo obsoletos, e que os 
consumidores se tornaram entorpecidos por essa estratégia de marketing em massa. 
A única maneira de se destacar em uma multidáo, na verdade, é ser brilhante. 

Entáo, aqui é onde os leitores cínicos comegam a aplaudir. Todo o falatório de 
marketing que vocé pode fazer náo é nada comparado ao poder de um conjunto de 
capacidades marcantes. Antes de você começar a dizer “Eu te disse”, nós provavel- 
mente devíamos conversar sobre a definição de marcante. 

Marcante definitivamente náo significa o mesmo que “bom”. Geralmente, pro- 
dutos que sáo marcantes sáo bons. Mas produtos que sáo bons sáo raramente mar- 
cantes. Ser marcante significa que algo merece sua atengäo. Vocé náo vai se tornar 
um marcante desenvolvedor de software simplesmente por ser melhor do que outros 
programadores que vocé conhece. 

Ser melhor do que alguém náo é algo suficiente para resultar no aumento da sua 
reputagäo. Se alguém perguntar, pode ser que vocé tenha um conjunto de indicagöes 
brilhante, mas ser marcante significaria que as pessoas conversaram sobre vocé antes 
que lhes perguntassem. 

Para ser marcante, vocé deve ser significativamente diferente daqueles ao seu re- 
dor. Muitas das estratégias de marketing pessoal discutidas nesse capítulo sáo mon- 
tadas focadas na notoriedade. 

Langar softwares open source bem sucedidos, escrever livros e artigos, e dar pa- 


lestras em conferéncias podem contribuir para aumentar sua notoriedade. 


Faga demonstragöes ou morra! 


Se vocé reler o último parágrafo, embora náo seja uma lista exaustiva, vocé notará 
que cada um dos itens que eu incluí como sendo potencialmente marcante envolve 
fazer algo. Vocé pode ser o mais esperto ou o mais rápido, mas apenas ser náo é 
bom o suficiente. Vocé precisa estar fazendo. 

Godin usa a expressáo vaca roxa (purple cow) para nos lembrar do que é neces- 
sário para ser marcante. Náo é a melhor vaca, ou a vaca mais leiteira, ou a vaca 
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mais bonita. Uma vaca roxa iria se destacar em um meio de vacas melhores, mais 
leiteiras e mais bonitas. Seria sobre a vaca roxa que vocé falaria depois de ver esse 
grupo. 

O que você poderia fazer que tornaria a si mesmo e suas realizações como a 
vaca roxa? Náo apenas seja mestre em um assunto — escreva um livro sobre isso. 
Escreva geradores de código que tornem o que costumava ser um processo de uma 
semana para um de cinco minutos. Em vez de ser respeitado entre seus colegas de 
trabalho, torne-se a autoridade mais reconhecida de sua cidade no que diz respeito a 
tecnologia na qual você se foca. Faça algo previamente impensável em seu próximo 
projeto. 

Náo deixe que vocé seja apenas o melhor em um grupo. Seja o cara e faca coisas 
sobre as quais as pessoas náo podem deixar de falar. 


Faca algo 


1) Comece pequeno, mas tente fazer algo marcante em seu atual projeto ou traba- 
Iho. Uma das maneiras de experimentar isso é tentar alcangar uma produtividade 
marcante. Agendas de projeto normalmente sáo sobrecarregadas. Encontre algo 
que todos pensam que precisará de uma semana para ser feito e faça em um dia. 
Trabalhe horas extras para isso se você achar necessário. Você não precisa fazer 
disso um hábito, mas sim, levar isso como um experimento. Faça o trabalho em 
um período de tempo marcante. Veja se as pessoas “notam”. Se não, por que não? 


Se sim, de que forma? Afine as variáveis e tente de novo. 
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CAPÍTULO 43 


Fazendo o gancho 


Quando eu era um jovem saxofonista no Arkansas, as pessoas me perguntavam “Oh, 
vocé conhece o Chris?” — eu náo o conhecia. Aparentemente, ele era o outro ado- 
lescente na cidade que era um sério aspirante a músico de jazz. Entáo, quando as 
pessoas me viam, eles faziam a óbvia conexáo, esperando que fóssemos camaradas 
em nossa caminhada jazzística colegial. 

No veráo, eu tive a oportunidade de ver a Count Basie Jazz Orchestra tocar em 
um show ao ar livre em um anfiteatro nas margens do rio Arkansas. Com uma com- 
binagäo de bom humor e uma coragem descomunal, acabei conseguindo conversar 
com os músicos no backstage, antes do show. Eu nunca fui uma pessoa muito con- 
versadora, entáo isso foi realmente uma vitória. Eu fiquei nos fundos conversando 
com um dos saxofonistas da orquestra, quando outra jovem crianga chegou e come- 
cou a conversar. Depois de cinco ou dez minutos, a banda começou, deixando-nos 
desacompanhados. “Você é o Chris/Chad?” — nós dissemos simultaneamente. 

Nos anos que vieram, eu passei bastante tempo com Chris. Ele, eu logo aprendi, 
tinha uma estranha aptidáo para se associar aos melhores músicos da cidade. Ele era 
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apenas um menino da escola. Porém, ele já fazia shows, como substituto do pianista 
de jazz mais respeitado do Little Rock. Chris era muito bom — especialmente para 
sua idade — mas ele náo era táo bom. 

Näo me levou muito para entender o que estava acontecendo. Nós saiamos, vá- 
rias vezes por semana, a clubes onde se tocava jazz. Sempre era, de alguma forma, 
uma experiéncia desconfortável para alguém introvertido como eu, mas, cronome- 
tradamente, quando a banda fazia um intervalo, Chris interrompia o assunto e me 
deixava para conversar com os músicos. Ele era como um robó. Eu preciso admitir, 
era um pouco enjoativo assisti-lo. Era táo previsível. Ele náo estava incomodando 
os pobres músicos? Eles estavam fazendo um intervalo, pelo amor de Deus. Eles náo 
queriam conversar com essa criança! Tendo sido deixado de lado, ou eu tinha que 
segui-lo ou ficar sentado sozinho esperando. Ocasionalmente, quando eu náo tinha 
muita energia, escolhia o segundo. Entretanto, na maioria das vezes eu o seguia e 
tentava fingir que me encaixava. 

Frequentemente, até demais para a minha surpresa, os músicos pareciam gostar 
de conversar com Chris — e mesmo comigo. Ele era muito intrometido e sempre 
ficava pedindo para se sentar com a banda, por mais inapropriado que me parecesse. 
Ele também pedia aos músicos por aulas, o que significa que ele ia a suas casas para 
ouvir música e conversar sobre jazz. Algumas vezes eu era arrastado junto, com a 
mesma sensagäo que eu tinha nos intervalos dos shows — que eu estava incomo- 
dando. 

Mas obviamente era eu que estava confuso com o relacionamento que Chris es- 
tava desenvolvendo com aqueles músicos. Ele estava tornando o sonho real, tocando 
com músicos realmente bons. Foi ele quem me conduziu aos melhores músicos da 
cidade. Sendo que a única diferenga entre nös era que ele era extrovertido. 

Como passar dos anos, sua estratégia de “ser o pior”, aliada a habilidade de desca- 
radamente se forgar para os outros, fez com que ele se tornasse um incrível pianista. 
De fato, ele achou sua fresta para tocar com músicos de jazz realmente famosos. Eu, 
por outro lado, ainda era o mesmo cara que ele conheceu. Ele me empurrou para al- 
guns desses shows de perfil “mais elevado”, mas era sempre ele que dava o empurráo 
— nunca o inverso. 

Desde então, tenho visto o mesmo padrão nas pessoas que conheci em música 
clássica, na Comunidade Americana de Budismo Tibetano, desenvolvimento de soft- 
ware, e mesmo nos confins de um simples escritório. Chris chamava isso de “fazer 
o gancho”, o que o tornava ainda mais repulsivo para mim. Mas o resumo da histó- 
ria é este: as pessoas realmente boas não se incomodam se você quiser conhecê-las. 
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As pessoas gostam de ser apreciadas e gostam de conversar sobre os assuntos pelos 
quais sáo apaixonados. O fato de elas serem o profissional, ou o guru, ou o líder, ou 
o autor renomado náo muda o fato de que sáo humanos e gostam de interagir com 
outros humanos. 


O medo nos separa dos profissionais. 


Falando por mim mesmo (e extrapolando a partir daí), a barreira mais séria entre 
nós, mortais, e as pessoas que admiramos é nosso próprio medo. Associar-se a pes- 
soas espertas e bem conectadas, que podem ensinar-lhe coisas ou achar um trabalho 
para vocé, é possivelmente a melhor forma de se melhorar, mas muito de nós tém 
medo de tentar. Fazer parte de uma comunidade profissional coesa e bem integrada 
€ como músicos, artistas e outras pessoas da arte se tornaram fortes e evoluíram por 
anos. Os gurus sáo os pontos de partida nas redes sociais e profissionais. Tudo o que 
é preciso para estabelecer a conexáo é um pouco menos de humildade. 

É claro que você não precisa começar a conversar aleatoriamente. Obviamente 
você quer procurar aqueles com quem você tem algo em comum. Talvez você leia 
um artigo que o influenciou bastante. Você pode mostrar ao autor o trabalho que 
você fez como resultado, e pedir feedback. Ou talvez você possa criar uma interface 
de software para um sistema que alguém criou. Este é um ótimo e legítimo jeito de 
estabelecer a conexão. 

Obviamente, você pode fazer isso tanto on-line como pessoalmente. Uma cone- 
xão duradoura é uma conexão duradoura. Os heróis do mundo do software estão 
espalhados pelo mundo. O mesmo vale para a indústria musical, embora você não 
possa confiar que todos os músicos sejam conectáveis por e-mail. Então, o mundo da 
música tende a formar aglomerados profissionais locais, enquanto os desenvolvedo- 
res de software têm a vantagem de serem facilmente alcançáveis, onde quer que você 
esteja. Isso torna fácil não apenas encontrar os gurus de sua cidade, como também 
qualquer guru. Algumas das mentes mais influentes do desenvolvimento de software 
estão prontamente acessíveis por e-mail e, até mesmo, por chat em tempo real. 

A história que me fez escrever este livro, na verdade, começou com um e-mail 
sobre uma biblioteca Ruby para um de seus editores, seguido de muitas conversas via 
chat on-line. Embora eu estava tímido ao mandar o e-mail inicial, aparentemente 
isso não irritou Dave, e aqui está você, lendo minhas palavras. Obrigado, Chris. 
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Náo podemos simplesmente...? 


por Stephen Akers 

Qualquer pessoa que já passou bastante tempo em seu trabalho sabe que existe 
uma luta entre tecnologia de informação (TI) e o negócio (aqueles que não são TT). 
A raiz deste conflito é quase sempre um mal-entendido, falha de comunicação e ex- 
pectativas mal gerenciadas. Esses assuntos são sublinhados quase diariamente por 
várias frases usadas por ambos os lados. 

Para TI, dentre as expressões mais odiadas estão: “Não podemos simples- 
mente...?” Geralmente ocorre algo como: Não podemos simplesmente terceirizar 
este serviço? Não podemos simplesmente colocar mais desenvolvedores no projeto? 
Não podemos simplesmente fazer o que fizemos da última vez? Não podemos sim- 
plesmente tornar a aplicação mais rápida? Não podemos simplesmente criar um 
novo banco de dados? 

O problema é que muitas das pessoas de TI, quando ouvem essa frase, se focam 
na palavra “simplesmente”. Isso os faz sentir como se as pessoas de negócio conside- 
rassem suas sugestões como óbvias, triviais, e facilmente alcançáveis. Qualquer falha 
na implementação iria, por conseguinte, indicar que aqueles de TI foram incapazes 
de completar a mais simples das tarefas e deviam ser substituídos. 

Como resultado, uma resposta comum a esses pedidos é frequentemente “não”. 
As pessoas de TI querem se assegurar de que as de negócio percebam que suas pro- 
postas não são apenas complexas e difíceis de executar, como são, de fato, uma ideia 
ruim. Eis o conflito. Em última análise, o que acontece é que as pessoas de negócio 
se distanciam, com a impressão de que TI sempre diz “não”, enquanto as de TI ficam 
com a ideia de que as pessoas de negócio não sabem o que está sendo feito. 

Isso é exatamente o que eu costumava pensar. Na minha opinião, o que o negó- 
cio realmente precisava era de alguém em sua equipe que sabia o que eles estavam 
fazendo. Este é o motivo pelo qual, em algum momento de minha carreira, eu re- 
solvi deixar TI e partir para os negócios. Eu realmente esperava que todos os meus 
projetos tivessem grande sucesso porque eu sabia como fazer as coisas do jeito certo. 

É engraçado como nossos planos nem sempre resultam naquilo que esperáva- 
mos. Embora eu tenha alcançado sucesso na equipe de negócios, não era assim que 
eu queria marcar este ponto. 

Ao contrário disso, eu descobri que ainda havia muito o que aprender. Por exem- 
plo: 


1) Existem fatores comerciais reais que agem como limitadores em praticamente 
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todos os projetos. Essas limitações vão, ás vezes, requerer que você implemente 
não menos que a solução técnica perfeita. 


2) Timelines propostas pelas pessoas de negócio geralmente não são tão arbitrárias 
quanto parecem. Em muitas vezes, o prazo de entrega de uma solução pode ter 
um efeito cascata no projeto ou mesmo na performance da empresa. 


Uma vez que eu aprendi essas lições, eu percebi que as pessoas de TI têm focado 
na parte errada da expressão “Não podemos simplesmente.” A palavra implícita 
operante nessa sentença, na verdade, é o sujeito nós. Esta palavra implica que o 
negócio está considerando a área de TI como uma parte crítica de sua equipe. Estão 
procurando o setor de TI por ajuda para formular uma solução que resultaria em 
sucesso para toda a empresa. 

Portanto, a próxima vez que você ouvir essa frase, tente combater a resposta au- 
tomatica “não”. Mantenha o foco na palavra “nós” e diga, com confiança, “sim, nós 
podemos colocar mais programadores no projeto, mas isso não seria uma boa ideia, 
porque..” Mas não pare por aí. Não é suficiente apenas explicar seu posicionamento. 
É preciso mergulhar mais fundo para descobrir sob quais limites comerciais o ne- 
gócio está operando. Com o tempo, isso lhe dará conhecimento sobre o domínio de 
negócio e oferecerá um melhor ponto de vista sobre os problemas que precisam ser 
resolvidos. A combinação disso com seu conhecimento técnico o fará progredir de 
alguém que sempre diz “não” para um parceiro sem o qual o negócio não poderia 
sobreviver. 


Stephen Akers é vice-presidente de TI na Genscape, Inc. [/box] 
Faça algo 


1) Escolha um de seus softwares favoritos e mande um e-mail para seu criador. Co- 
mece agradecendo-o pelo software. Então, faça uma sugestão, uma pergunta, ou 
faça outra tentativa de estabelecer um vínculo humano com ele. Solicite resposta. 
Se o software é gratuito ou open source, ofereça-se para ajudar de alguma forma. 


2) Pense em algum local para você, quem você admire ou de quem gostaria de apren- 
der algo. Procure uma situação em que você possa encontrar essa pessoa (uma 
reunião de um grupo de usuários ou palestras são ótimas oportunidades), e dê 
um jeito de começar uma conversa, mesmo se isso o deixar desconfortável — 
especialmente se você estiver desconfortável. 
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CAPÍTULO 44 


Já obsoleto 


Muitos de nós somos guiados pela a indústria de TI porque as coisas estáo sempre 
mudando. É um ambiente de trabalho fresco e excitante. Sempre há algo novo a 
aprender. Por outro lado, contudo, está o desanimador fato de que nossos investi- 
mentos duramente conquistados no meio tecnológico depreciam-se mais rápido do 
que um carro novo. A novidade de hoje é a tranqueira obsoleta de amanhá com vida 
útil limitada. 


Suas brilhantes novas habilidades já sáo obsoletas. 


Em Leading the Revolution [5], Gary Hamel fala sobre como os líderes incumben- 
tes de qualquer indústria se tornam complacentes e, com isso, desenvolvem pontos 
cegos. Quanto mais bem sucedido for seu negócio, é mais provável que vocé fique 
confortável com seu modelo de negócio, tornando-se incrivelmente vulnerável para 
aqueles que vém atrás de vocé com uma nova ideia radical — mesmo que seja es- 
túpida — que pode fazer com que seu maravilhoso e vitorioso modelo de negócio 
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pareça um suéter desgastado e velho largado em uma discoteca. O mesmo pode ser 
dito sobre escolhas de tecnologia. Se vocé domina a grande tecnologia do momento, 
como Java EE ou .NET, até o momento de publicação deste livro, talvez você esteja se 
sentindo extremamente confortável. É um lugar lucrativo, certo? Cada site de vagas 
de emprego, ou cada seção de classificados no jornal, serve como uma afirmação em 
sua decisáo. 

Cuidado. Sucesso gera arrogáncia, que gera complacéncia. Uma onda como J2EE 
pode dar a impressáo de que nunca vai acabar. Contudo, todas as ondas ou se dissi- 
pam, ou encontram a costa eventualmente. Muito conforto por muito tempo pode 
deixá-lo indefeso, imaginando o que vocé faria em um mundo sem J2EE. 

Dito isso, as pessoas tém anunciado a morte de COBOL por décadas. Cada novo 
incumbente é chamado de “o COBOL do século 21”, ou alguma variação disso. Nos 
dias de hoje, esse rótulo é aplicado a Java. Embora eu deteste encostar, ver, ou estar 
perto de código COBOL, chamar Java de COBOL do século 21 é um grande elogio. 
Mesmo que alguns de nós adoraríamos vê-lo sumir, COBOL está aqui, e tem operado 
por um longo tempo. Programadores COBOL têm trabalhado com essa linguagem 
durante suas carreiras inteiras. Isso realmente diz algo na montanha russa da indús- 
tria. É difícil dizer se o mesmo tipo de investimento funcionaria na economia de 
hoje. 

A história do COBOL é uma exceção — não a regra. Poucas tecnologias forne- 
cem plataforma para emprego tão duradoura. A mensagem aqui não é que você viva 
apenas com seu conhecimento em uma tecnologia mainstream. Isso seria irrespon- 
sável. Eu vou dizer que quanto mais mainstream for seu conhecimento, maior risco 
você terá de ser deixado na tecnologia da idade da pedra. 

Todos nós já ouvimos as extrapolações da lei de Moore, que diz que o poder de 
processamento duplica a cada 18 meses. Se os números estão corretos ou não, é fácil 
perceber que a tecnologia ainda está avançando com a mesma proporção do que fazia 
em 1965, quando Gordon Moore, da Intel, fez essa asserção. E com esses avanços no 
poder do hardware vêm os possíveis progressos do que fazer com softwares. 

O poder de processamento duplica. Com a tecnologia progredindo tão rapida- 
mente, há muita coisa acontecendo para qualquer pessoa acompanhar. Mesmo que 
suas habilidades sejam completamente atuais, se você não está praticamente no pro- 
cesso de aprender a Próxima Grande Coisa, é quase tarde demais. Você pode estar à 
frente da curva na onda atual e atrás da próxima. Timing se torna muito importante 


em um ambiente como este. 
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Vocé deve comecar a perceber que, mesmo se vocé está na crista da onda atual, 
vocé provavelmente já está atrás da próxima. Se timing é tudo, comece a pensar 
a frente com seus estudos. O que vai ser possível em dois anos, que ainda náo é 
agora? E se um espago de disco fosse táo barato que fosse praticamente gratuito? E 
se os processadores fossem duas vezes mais rápidos? O que náo precisariamos nos 
preocupar em otimizar? Como esses avangos mudam o que vai estourar no futuro? 

Sim, é uma aposta. Porém, é um jogo que vocé vai definitivamente perder se náo 
jogar. O pior dos casos é se vocé aprendeu algo enriquecedor que náo é diretamente 
aplicável em seu emprego em dois anos. Entáo ainda é melhor se vocé estiver olhando 
adiante e apostando nisso. O melhor caso é se vocé se mantiver a frente da curva e 
puder continuar a ser um expert em tecnologias de ponta. 

Olhar adiante e ser explícito sobre o desenvolvimento de suas habilidades pode 
fazer a diferenga entre ser cego ou visionário. 


Faca algo 


1) Separe um momento semanal para investigar o que virá como vanguarda. En- 
contre pelo menos duas horas por semana para pesquisar tecnologias e começar 
a desenvolver suas habilidades nelas. Ponha a máo na massa com essas novas 
tecnologias. Construa aplicações simples. Faça protótipos com a nova tecnologia 
nos trechos difíceis de seus projetos que usam a tecnologia atual para entender 
quais são as diferenças e o que as novas tecnologias permitem. 


Coloque isso na sua agenda. Não deixe de fazer. 
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CAPÍTULO 45 


Vocé já perdeu seu emprego 


O emprego para o qual vocé foi contratado já náo existe mais. Vocé pode ainda estar 
pensando em um salário. Vocé pode ainda estar agregando valor. Vocé pode ainda 
estar deixando seu chefe extasiado e feliz. Mas vocé já perdeu seu emprego. 

A coisa mais certa é que tudo está mudando. A economia está em constante 
movimento. Empregos se tornam offshore ou onshore. Os negöcios estáo tentando 
se adaptar. As coisas não alcançaram um ponto estável em nossa indústria. Ela está 
como um adolescente estranho passando pela puberdade. Estranho, feio, e diferente 
ano após ano — dia após dia. 

Portanto, se vocé foi contratado para ser um programador, náo pense em si 
mesmo como um programador. Pense em si mesmo como talvez náo mais um pro- 
gramador. Continue executando suas funções, mas não fique muito confortável. Não 
tente se acomodar com a identidade de um programador. Ou um designer. Ou um 
testador. 

De fato, não é mais seguro (como se antes fosse) identificar-se muito proxima- 


mente com o emprego para o qual foi contratado. Se as coisas ao seu redor estão 
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mudando, e o contexto no qual trabalha está em constante movimento, agarrar-se 
a sua funcáo cria uma dissonáncia náo saudável que contamina seu trabalho. Vocé 
pode se pegar querendo ser um programador, mas fazendo o trabalho de um gerente 
de projetos. E fazendo isso mal. 


Vocé näo é seu emprego. 


De volta a antes de perder seu emprego, vocé pode ter tido planos. Vocé pode 
ter imaginado seu progresso através dos ranks de sua empresa. Vocé cumpria suas 
horas como um designer e assumia o papel de arquiteto quando a recompensa era 
devida. Vocé podia ver a progressáo inteira de um arquiteto até um analista, até líder 
de equipe, através da cadeia de gestáo. 

Porém, vocé já perdeu seu emprego, e seus planos mudaram. Eles váo continuar 
mudando. A cada dia. É bom ter ambições, mas não se dedique cegamente a um 
futuro longo e imaginário. Você não pode se dar ao luxo de ter uma visão de túnel, 
onde só se vê algo tão distante no futuro. Se você busca atingir algum alvo em mo- 
vimento, você não mira propriamente no alvo. Você mira no lugar ao qual o alvo 
deve ir. O caminho daqui até lá não é mais uma linha reta. É um arco, na melhor das 
hipóteses, mas é mais provável que seja um rabisco amórfico. 


Faça algo 


1) Se você é um programador, tente por um dia ou dois fazer seu trabalho como se 
você fosse um testador ou um gerente de projeto. Quais são os vários papéis que 
você poderia ter dia após dia, que você nunca explicitamente considerou? Faça 
uma lista e tente experimentá-los. Passe um dia em cada. Talvez você nem mude 
os resultados do seu projeto, mas você verá seu trabalho de um jeito diferente. 
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CAPÍTULO 46 


Caminhe sem destino 


Um dos maiores problemas da América é que ela é uma sociedade guiada por metas. 
Somos uma nagäo de pessoas que sempre estáo focadas no resultado de um processo, 
seja o processo de aprendizado, a carreira de alguém, ou mesmo dirigindo com seu 
carro. Somos táo focados no resultado que esquecemos de olhar para o cenário como 
um todo. 

Se vocé pensar sobre isso, o foco no resultado é logicamente o inverso daquilo 
com que nós deveríamos estar perdendo nosso tempo. Vocé tipicamente passa todo 
seu tempo fazendo coisas, e pouco tempo realmente atingindo metas. Por exemplo, 
quando vocé está desenvolvendo software, o processo durante o desenvolvimento é 
onde vocé passa todo seu tempo, e náo no final do projeto, quando tudo está pronto. 

Isso também é válido para sua carreira. O alimento real de sua carreira náo sáo 
promoções e aumentos de salário. É o tempo que você gasta trabalhando em dire- 
cáo a esses avangos. Ou, mais importante, € o tempo que vocé passa trabalhando 
independentemente dos avanços. 


Se esse é o núcleo da sua vida profissional — o verdadeiro trabalho — então você 


Casa do Código 





já chegou ao seu destino. O seu pensamento focado no destino e focado nos objetivos 
apenas o guia de uma meta a outra. Náo existe um fim lógico. O que muitos de nós 
não conseguem entender é que o caminho é o fim. 

De volta ao exemplo do desenvolvimento de software, é fácil se envolver demais 
com a entrega do código que você está criando. Seu cliente precisa de uma aplicação 
web, e você se foca em terminar tal projeto. Mas uma aplicação viva nunca está 
“concluída”. Um lançamento conduz ao outro. Foco demasiado no produto final nos 
distrai da verdadeira entrega: o desenvolvimento sustentável de uma nova entidade. 


Concentre-se em fazer, não no que está sendo feito. 


Focar no final faz com que você esqueça de fazer o processo direito. E processos 
ruins criam produtos ruins. O produto deve ter seus requisitos mínimos, mas seu 
interior será feio. Você se otimizou para a meta a curto prazo — e não para o futuro 
inevitável e contínuo do desenvolvimento do produto. 

Não apenas processos ruins fazem produtos ruins, mas produtos ruins fazem 
processos ruins. Uma vez que você tem um desses produtos que são bagunçados em 
seu interior, seus processos se adaptam a isso. As janelas quebradas de seu produto 
levam a janelas quebradas em seu processo. É um ciclo vicioso. 

Portanto, em vez de constantemente se perguntar “Já estamos lá? Já estamos lá?” 
perceba que a única resposta saudável é “sim”. É como você cruza o caminho que é 
importante, e não o destino. 


Faça algo 


1) Em seu livro The Miracle of Mindfulness [6], Thich Naht Hanh apresenta uma 
sugestão: a próxima vez que você tiver que lavar a louça, não o faça para tê-las 
limpas. Tente apreciar a experiência de lavar a louça. Não se concentre em ter- 
minar. Foque-se no ato de lavá-las em si. 


Lavar a louça é uma tarefa mundana que quase ninguém saboreia. Desenvolve- 
dores de software fazem algo semelhante em um dia normal, como lidar com a 
pressão do tempo e relatórios de gastos, por exemplo. A próxima vez que você ti- 
ver que fazer uma tarefa como essa, veja se há um jeito de focar na tarefa enquanto 
você a realiza, em vez de ansiosamente se apressar para concluí-la. 
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CAPÍTULO 47 


Trace um roteiro 


Quando você está em “modo manutenção”, é fácil pegar um ritmo e simplesmente 
continuar a ser como você é. Como um desenvolvedor de software, você sabe que 
isso acontece pela sua experiência com sistemas. Se você mantém uma aplicação ou 
uma biblioteca que outros desenvolvedores usam, ela vai estagnar no modo de cor- 
reção de bug (ou pior) ao menos que você tenha um sólido roteiro. Você pode fazer 
as melhorias ocasionais devido a pedidos dos usuários ou por necessidade própria, 
mas o código eventualmente vai atingir um estado estável e mudará em uma taxa 
exponencialmente mais lenta, porque você o considera pronto. 

Contudo, uma aplicação viva nunca está concluída, ao menos que esteja no ca- 
minho para a aposentadoria. O mesmo é válido para sua carreira. A não ser que você 
esteja procurando sair do meio, você precisa de um roteiro. Se a Microsoft tivesse 
considerado o Windows 3.1 pronto, todos nós estaríamos usando Macs agora. Se os 
desenvolvedores Apache tivessem considerado seu servidor pronto quando fizeram 


o 1.0, eles não estariam esmagadoramente liderando o mercado agora. 


O seu roteiro pessoal para seu produto é o que você usa para dizer se você pro- 
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grediu ou náo. Quando vocé vai para o mesmo escritório dia após dia, para trabalhar 
em muitas das mesmas coisas, o cenário ao seu redor náo muda. Vocé precisa colocar 
indicadores que vocé possa ver a distáncia, de modo que possa saber se realmente 
saiu do lugar. As funcionalidades do seu produto sáo esses indicadores. 

Ao menos que vocé realmente pegue isso e faga um plano, vocé náo conseguirá 
ver além do próximo pontinho no horizonte. Nos capítulos 2 e 3, vocé descobriu 
como escolher o caminho de sua carreira e como investir em sua vida profissional. 
Embora eu tenha focado no que parecia ser uma escolha de uma única vez sobre 
aquilo em que investir, cada escolha deveria ser parte de algo maior. Pensar em cada 
novo conhecimento ou habilidade como equivalentes a uma simples característica de 
uma aplicacáo traz muito bem esse conceito. Uma aplicacáo com uma característica 
náo é muito uma aplicacáo. 

Além do mais, uma aplicação com um grupo de características que não sejam 
coesas vai confundir seus usuário. Seria isso um caderno de endereços ou uma 
aplicação de chat? É um jogo ou um browser? Um roteiro pessoal para seu pro- 
duto pode não apenas ajudá-lo a seguir seu caminho, constantemente evoluindo, mas 
também lhe dar uma visão geral do que você tem a oferecer. Ele pode mostrar que 
nenhuma característica única se mantém. Cada novo investimento é parte de um 
todo maior. Algumas funcionam fabulosamente bem juntas, outras requerem um 
grande salto mental para os potenciais empregadores. Seria ele um administrador 
de sistema ou um designer gráfico? Seria ela uma arquiteta de aplicação ou um 
guru de automação de QA? 

Embora seja definitivamente ok aprender diversas coisas — pois isso expande 
seu pensamento — também é uma boa ideia pensar sobre a história que seu con- 
junto de habilidades conta. Sem um roteiro, sua história pode parecer mais com um 
romance de Jack Kerouac do que com um coeso grupo de competências logicamente 
relacionadas. Sem um roteiro, você pode realmente até se perder. 


Faça algo 


1) Antes de colocar no mapa o lugar para o qual você quer ir, ele pode ser um roteiro 
informativo e encorajador sobre onde você esteve. Pegue um tempo para explici- 
tamente escrever a linha do tempo de sua carreira. Mostre onde você começou e 
quais eram suas habilidades e empregos em cada fase. Note os pontos onde você 
fez melhorias incrementais e onde você pareceu realizar grandes saltos. Observe 
a duração média necessária para fazer um avanço considerável. Você pode esta- 
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belecer metas mais objetivas para si se tiver uma imagem clara do histórico de se 
progresso. Uma vez que vocé criou esse mapa histórico, mantenha-o atualizado. 
É uma ótima maneira de refletir seu progresso conforme você move em direção 
ao seus objetivos recém estabelecidos. 
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CAPÍTULO 48 


Observe o mercado 


Você seria tolo se investisse seu dinheiro em uma ação volátil e depois ignorá-la. 
Mesmo se vocé fez muita pesquisa e fez uma escolha proposital sobre em quem in- 
vestir, o mercado é incerto. Você não pode simplesmente atirar e se esquecer, quando 
se trata de investimentos. Mesmo se o valor de uma ação está aumentando agora, isso 
não significa que ele não vai começar a afundar amanhã. 

Além disso, você pode estar perdendo uma oportunidade. Talvez você pense 
que seja um porto seguro estar rendendo um retorno de 10% no ano. Isso parece 
realmente um bom negócio, se o resto do mercado não está de repente fazendo muito 
melhor que 10%. Seu principal investimento de hoje, mesmo se continuar a agir, pode 
não ser muito impressionante se comparado com o que será possível amanhã. 

Na medida em que as condições do mercado mudam, não prestar atenção pode 
resultar em perda de dinheiro ou perda de dinheiro que se poderia ganhar. 

O mesmo é válido para seu investimento em conhecimento. Java é a escolha con- 
servadora dos dias de hoje. O que poderia mudar, que poria em questão tal verdade? 
Como você poderia saber se isso mudou? 
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E se, por exemplo, a Oracle comegasse a dar sinais de faléncia? No passado, a Sun 
Microsystems, que mantinha o Java, perdeu sua posigáo dominante, e Java náo era 
um padráo aberto. Embora hoje seja open source, é ditado e desenvolvido pela Ora- 
cle. Em qualquer momento, uma moribunda Oracle pode tentar subitamente fazer 
de sua linguagem e de sua máquina virtual um centro lucrativo. Isso pode fragmen- 
tar a linguagem Java com mudangas incompativeis, gerando um pánico enorme. 

Com sua cabeça focada no código do seu monitor, talvez você nem ouça falar 
de algo como isso antes de ser tarde demais. Você pode se ver no mercado com 
uma habilidade com valor subitamente diminuto. Essa é uma situação hipotética 
improvável, mas algo parecido pode acontecer. 

O mais provável é que, você estando confortável em seu emprego atual, com 
suas competências atuais, você pode se tornar um ignorante feliz conforme a Nova 
Grande Coisa desponta. Vinte anos atrás, você teria ficado surpreso ao descobrir o 
quão grandes linguagens orientadas a objeto com Gargabe Collection se tornariam. 
Porém, definitivamente havia sinais, se você os estivesse observando. Daqui a 10 
anos, quem sabe qual será a nova grande revolução? 

Você deve manter seus olhos e ouvidos abertos. Observe as novidades tecnoló- 
gicas, tanto pelo viés empresarial como pelo lado técnico puro, à procura de desco- 
bertas que podem provocar uma onda. Como Tim O’Reilly (http://tim.oreilly.com/) 
‚da O'Reilly and Associates, diz, observe os geeks alfa. Os geeks alfa são aqueles su- 
pernerds que estão sempre no mais alto topo do mais alto cume, ao menos em seus 
hobbies. A afirmação de Tim, que eu tenho desde então observado, é que se você 
consegue achar essas pessoas e ver em que eles estão mergulhados, você pode ter um 
vislumbre do que potencialmente pode ser grande em um ou dois anos. É estranho 
como isso funciona bem. 


Observe os geeks alfa. 


Independentemente da escolha que você fizer, é preciso estar atento ao fato de 
que, no setor de tecnologia, o que é um bom investimento hoje eventualmente não 
será mais um bom investimento. E, se você prestar atenção ao estado de espírito do 


mercado, isso raramente vai pegá-lo de surpresa. Você não quer esse tipo de surpresa. 
Faça algo 


1) Passe o próximo ano tentando se tornar um dos geeks alfa. Ou, ao menos, faça o 
gancho com um. 
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CAPÍTULO 49 


Aquele gordo no espelho 


Infelizmente, estou acima do peso. Já faz tempo. Porém, quando eu morava na Índia, 
eu perdi muito peso. Parte disso foi por causa da dieta. Parte, pelos exercicios. Mas a 
maior parte foi por ficar doente. Depois que voltei aos Estados Unidos, eu lentamente 
ganhei peso de novo. Era uma coisa desapontadora, á qual reagi me matriculando 
em uma academia e contratando um personal trainer. O peso voltou a diminuir. 

Passei por diversas dessas oscilações. O que é fascinante disso tudo é que eu não 
consigo realmente notar quando estou ganhando ou perdendo peso. A única forma 
de eu saber é se alguém me disser ou se minhas roupas de repente pararem de caber. 
Minha esposa me vê todo dia, de modo que ela também não consegue notar — e, nos 
Estados Unidos, as pessoas geralmente não falam nada se você engordar. Na Índia, 
sim. 

Eu não reparo porque me vejo muito frequentemente. Se você é constantemente 
exposto a algo, é difícil notar que ele está mudando, ao menos que a mudança acon- 
teça rapidamente. Se você sentar e observar uma flor desabrochar, vai passar bastante 
tempo até que você note que algo aconteceu. Entretanto, se você sair e voltar em dois 
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dias, verá algo muito notável diferente de quando vocé saiu. 

Vocé perceberá o mesmo fenómeno com sua carreira. Na verdade, vocé náo 
notará. Este é o problema. Vocé pode olhar para si mesmo pelo espelho metafórico 
todo dia e não ver nenhum traço de mudança. Você parece tão bem ajustado quanto 
antes. Você parece tão competitivo quanto antes. Suas habilidades parecem ser tão 
atualizadas quanto antes. 

Então, de repente, um dia seu emprego (ou seu negócio) não se encaixa mais 
com você. Parece apenas desconfortável no início, mas você já alcançou um ponto 
crítico, no qual você precisa ou agir rapidamente ou comprar um novo par de calças 
(metafóricas). 

Quando se trata de flutuações de peso corporal, você tem uma balança, então 
é razoavelmente fácil mensurar seu progresso (ou falta dele, no meu caso). Infeliz- 
mente, não há balança para medir seu poder de marketing ou suas habilidades de 
programador. Se houvesse, poderíamos colocá-la em uma tabela e autogerar seus 
salários. Já que isso não existe, você terá que criar uma para si mesmo. 

Um jeito fácil de medir seu progresso é usar pessoas confiáveis. Um mentor ou 
um colega próximo podem ajudar a dar um olhar mais objetivo sobre onde você está. 
Você pode discutir suas habilidades de desenvolvedor de software, líder de projeto, 
comunicador, membro de equipe, ou qualquer outra faceta do pacote total que o faz 
quem você é. Na GE, esse é um processo chamado de “revisão 360”, que formaliza 
a ideia e encoraja os funcionários a procurar por feedback de seus parceiros, seus 
chefes e clientes internos. Esse processo é uma ótima forma de obter um número de 
diferentes perspectivas de si mesmo como um funcionário. 


Desenvolvedor, reveja-te a ti mesmo. 


A coisa mais importante para se trazer à tona, conforme você passa por um pro- 
cesso como este (seja sozinho ou com ajuda), é onde estão seus pontos cegos. Você 
não precisa consertar todos eles. Você apenas deve saber onde eles estão. Sem ser 
específico, você será cego aos seus pontos cegos. É aí que as coisas ruins acontecem e 
o pegam desprevenido. Coisas ruins acontecem, então é melhor saber que elas estão 
vindo. 

Mesmo se você tivesse uma balança mágica de valores na qual você pudesse se 
medir, ela não lhe faria bem a não ser que você realmente a usasse. Agende suas re- 
visões. Você não vai parar para refletir, ao menos que você torne o tempo de reflexão 
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explícito. Dizer “Náo esquecer de pedir por feedback” náo € uma mensagem sufi- 
cientemente forte. Se vocé possui um calendário que tenha lembretes em pop-up, 
marque compromissos consigo mesmo para autoavaliacáo. Primeiro, determine seu 
sistema de medida, e entáo, coloque-o na agenda. Se náo for uma parte intrínseca 
de sua vida profissional, vocé náo o fará. 

Se sua empresa já realiza tais processos, náo os trate como algo nonsense de RH. 
Leve-os a sério, e faga algo de bom sair disso. Eles podem ter sido implementados 
de um jeito pobre no seu trabalho, mas a motivação (pelo menos o que costumava 
ser motivação) para eles ainda continua de pé. 

Finalmente, quando você tiver seu próprio sistema, e tiver agendado tempo para 
aplicá-lo, guarde os resultados por escrito. Mantenha sua avaliação em algum lugar 
próximo. Reveja-o e revise-o com frequência. Ligar o processo de autoavaliação a 
um registro físico o tornará concreto. 


Não deixe que coisas antigas o prendam como um par de calças apertadas. 
Aja nisso! 


1) Faça uma revisão 360. 


e Faça uma lista de pessoas confiáveis, com as quais se sente confortável em 
pedir feedback. Essa lista deve, preferencialmente, conter representantes de 
seus colegas, clientes e chefes (e subordinados, se você tiver algum). 


e Faça outra lista de aproximadamente 10 características que você acredita 
que sejam medidas importantes suas como um profissional. 


e Converta essa lista em um questionário. Nele, peça aos participantes para 
lhe darem nota em cada aspecto. Inclua também a questão “O que eu devia 
ter perguntado?” 


e Distribua o questionário para uma lista de pessoas de sua confiança. Peça 
aos seus avaliadores que façam críticas construtivas. O que você precisa é 
de feedback honesto — e não puxa-saquismo. 


2) Depois de receber as respostas, leia-as e compile uma lista de ações que você to- 
mará como resultado. Se você fez as perguntas certas para as pessoas certas, você 
terá alguns itens acionáveis. Compartilhe o resultado de seu questionário com 
seus avaliadores — não as respostas, mas as mudanças resultantes que você pla- 
neja fazer. Lembre-se de agradecer. Repita o processo ocasionalmente. 
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Comece a manter um diário. Pode ser um blog, como discutimos em 39, ou um 


diário pessoal. Escreva sobre o que vocé está fazendo, o que está aprendendo e 
suas opiniöes sobre o negócio. 


Depois que vocé estiver mantendo o diário por algum tempo, releia registros an- 
tigos. Vocé ainda concorda? Eles parecem errados? O quanto vocé mudou? 


CAPÍTULO 50 


A armadilha de macaco da Índia do 
Sul 


Em Zen and the Art of Motorcycle Maintenance [8], Robert Pirsig conta uma história 
sobre como as pessoas no sul da Índia costumavam capturar macacos. Eu náo sei se 
isso é verdade, mas nos ensina uma ligáo útil, portanto vou parafraseá-lo. 

As pessoas na Índia do Sul, tendo sido importunadas por macacos por vários 
anos, desenvolveram um engenhoso jeito de capturá-los. Eles cavavam um buraco 
longo e estreito no cháo, e usavam um objeto igualmente longo para alargar o fundo 
do buraco. Entáo, jogavam arroz na parte mais larga do fundo. 

Macacos gostam de comer. De fato, essa é uma grande parte do que os torna tais 
pestes. Eles pulam nos carros ou arriscam correr no meio de multidóes para roubar 
comida de suas máos. As pessoas da Índia do Sul estáo cientes disso. (Acredite-me, é 
surpreendentemente perturbador estar sentado, tranquilo, e de repente aparecer um 
macaco safado para roubar algo seu.) 


De acordo com Pirsig, os macacos apareciam, descobriam o arroz e esticavam 
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seus braços pelo buraco. Suas mãos alcançavam o fundo. Eles pegavam vorazmente o 
máximo de arroz possível, fechando as mãos em punho. Assim fechadas, elas cabiam 
na parte mais larga do buraco, mas o resto da abertura era estreita demais para que 
os macacos puxassem seus punhos cheios de arroz de volta. Eles ficavam presos. 

É claro, eles podiam simplesmente largar a comida e sair livres. 

Mas macacos dão grande valor à comida. Aliás, dão tanto valor que não conse- 
guem se forçar a desistir. Eles vão apertar o arroz até que ele saia do chão ou morrerão 
tentando tirá-lo de lá. Este último era o que geralmente acontecia. 

Pirsig conta essa história para ilustrar um conceito que ele chama de rigidez de 
valor. É o que acontece quando você acredita tão fortemente no valor de alguma 
coisa que você não consegue mais questioná-lo objetivamente. Os macacos valori- 
zavam tanto o aroz que, quando forçados a escolher entre o arroz em cativeiro e a 
morte, não conseguiam ver que deixar a comida era a coisa certa a se fazer naquele 
momento. A história faz os macacos parecerem muito estúpidos, mas a maioria de 
nós tem nossos próprios equivalentes ao arroz. 

Se lhe perguntassem se é uma boa ideia ajudar a alimentar crianças famintas em 
países em desenvolvimento, você provavelmente diria “sim”, sem pensar. Se alguém 
tentasse argumentar com você, você o acharia louco. Este é um exemplo de rigidez 
de valor. Você acredita nessa coisa tão fortemente que não consegue imaginar não 
acreditar nisso. Claramente, nem todos os valores que consideramos rígidos são 
ruins. Para a maior parte das pessoas, religião (ou a falta dela) também é um conjunto 
de crenças pessoais e de valores inabaláveis. 

Porém, nem todos os valores rígidos são bons. Além disso, muitas vezes algo que 


é bom em uma determinada circunstância não é boa em outra. 


Valores rígidos o tornam frágil. 


Por exemplo, é fácil se desligar das escolhas tecnológicas. Especialmente quando 
a tecnologia que escolhemos é underground. Nós amamos tanto tecnologia e colo- 
camos um valor tão alto quando a defendemos para ser adotada, que vemos cada 
oportunidade como uma batalha em que vale a pena lutar — mesmo quando estamos 
defendendo o que claramente é a escolha errada. Um exemplo que encontro (e pelo 
qual provavelmente me sinto culpado) é a base de fãs superzelosa de Linux. Muitos 
dos usuários Linux colocariam Linux no desktop de qualquer recepcionista, assis- 
tente, e vice-presidente da corporação sem levar em consideração que, em termos 
de usabilidade, as ferramentas simplesmente não são tão compatíveis com muitos 
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dos softwares comerciais disponíveis para um sistema operacional comercial. Vocé 
fica com cara de bobo e faz seus clientes infelizes quando vocé dá o software certo 
para as pessoas erradas. 

É difícil perceber que vocé está emagrecendo porque vocé se vé todo dia. Rigidez 
de valor funciona do mesmo modo. Desde que vivemos todo dia na mesma carreira, 
é fácil desenvolver rigidez de valor em nossas escolhas de carreira. Sabemos o que 
funcionou, e continuamos fazendo isso. Ou, talvez vocé sempre quis ser promovido 
à gerência, então você continua se esforçando para este objetivo, independente de 
quanto você gosta de apenas programar. 

Também é possível que a tecnologia de sua escolha se torne obsoleta, deixando- 
lhe subitamente sem uma base na qual se apoiar. Como um sapo em uma panela 
lentamente aquecendo, você pode de repente se ver em uma situação ruim. Muitos 
de nós, na metade dos anos 90, só pensávamos em Novell NetWare quando se tratava 
de disponibilizar arquivo e imprimir serviços na empresa através de uma rede. A 
Novell estava muito além de seu tempo com seu produto de serviços de diretório, e 
muitos de nós “do conhecimento” éramos quase arrogantes na crítica às tecnologias 
concorrentes. O produto da Novell estava desfrutando de uma saudável liderança no 
mercado, e era difícil imaginar a maré mudando. 

Nenhum evento sozinho tornou óbvio que a Novell estava perdendo para a Mi- 
crosoft. A Microsoft nunca fez o lançamento mágico de um Active Directory, que 
nos fizesse dizer “Uau, já era NetWare!” Mas a NetWare lentamente foi de inova- 
ção para tecnologia legada. Para muitos administradores da NetWare, a água estava 
fervendo antes de eles sequer perceberem que a panela estava morna. 

Se é esse o caminho que sua carreira está tomando, ou as tecnologias que você 
defende e nas quais investe, tome cuidado com as armadilhas de macaco. Aquelas 
escolhas originalmente intencionais podem se tornar o último punhado de arroz que 
você está segurando antes de sua carreira apanhar até a morte. 


Faça algo 


1) Encontre suas armadilhas de macaco — quais são suas presunções rígidas? 
Quais são os valores que guiam suas ações diárias sem você conscientemente sa- 
ber? 


Faça uma tabela com duas colunas: “Carreira” e “Tecnologia”. Embaixo de cada 
uma, liste os valores que você considera como verdades inabaláveis. Por exemplo, 
sob “Carreira”, o que você sempre considerou como sendo um de seus pontos 
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fortes? Ou fraquezas? Qual é o objetivo de sua carreira (“Eu quero ser CEO”)? 
Quais sáo as maneiras certas de alcancar sua meta? 


Na coluna “Tecnologia” liste o que vocé mais valoriza sobre as tecnologias nas 
quais escolheu investir. Quais sáo os atributos mais importantes de uma tecno- 
logia que deviam ser considerados ao fazer uma escolha? Como vocé faz um 
sistema de medida? Qual o ambiente mais produtivo para desenvolvimento de 
software? Quais sáo as melhores e piores plataformas, em geral? 


Quando vocé tiver sua lista e vocé considerá-la razoavelmente completa, vá item 
por item e mentalmente inverta cada afirmação. E se o oposto de cada asserção 
fosse verdadeiro? Permita-se honestamente desafiar cada uma. 


Essa é uma lista de suas vulnerabilidades. 


Conhega seu inimigo — pegue a tecnologia que vocé mais odeia, e faca um pro- 
jeto usando-a. Desenvolvedores tendem a separar-se entre os campos concorren- 
tes. As pessoas de .NET odeiam J2EE, e as pessoas de J2EE odeiam .NET. Pessoas 
de UNIX odeiam Windows, e vice-versa. 


Escolha um projeto fácil e tente fazer uma ótima aplicação usando a tecnologia 
que você odeia. Se você é uma pessoa de Java, mostre aqueles de NET como 
um desenvolvedor de verdade usa a plataforma! Na melhor das hipóteses, vocé 
aprenderá que a tecnologia que você odeia não é tão ruim e que, aliás, é possível 
desenvolver bom código com ela. Você também terá uma (certamente subde- 
senvolvida) nova habilidade que você talvez precise usar no futuro. No pior dos 
casos, o exercício será uma sessão de prática para você, e você terá mais recursos 
para seus argumentos. 


CAPÍTULO 51 


Evite planejamento de carreira do 
modelo cascata 


No comeco deste milénio, formou-se uma rebeliáo inicialmente pequena na indús- 
tria de software. Um grupo de especialistas em desenvolvimento de software come- 
¿ou a perceber que, entre eles, estava se formando uma tendência tanto em projetos 
de software que estavam falindo ou tendo sucesso. Em um ambiente industrial, em 
que mais projetos estão falindo do que tendo êxito, eles acreditavam que tinham 
descoberto uma forma de fazer melhor. O grupo se autodenominou Agile Alliance. 

A indústria, naquela época, se levou a acreditar que o único jeito de desenvolver 
projetos de software era seguir um processo rigoroso, cautelosamente planejado do 
topo ao fim. Analistas definiam requisitos em longos documentos, enquanto arqui- 
tetos enviavam suas criações para os designers, que criavam designs detalhados. O 
produto disso era passado a desenvolvedores que o transformavam em código, em 
alguma linguagem de programação. Finalmente, após meses — às vezes anos de es- 
forço —, o código era integrado e entregue a um grupo de teste, que o certificaria 
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para implementação. 

Às vezes, alguma variante desse processo funcionava. Se todo mundo soubesse 
cada detalhe necessário no começo de um projeto, esse tipo de planejamento e rigor 
podia vir a entregar um software bem pensando e com qualidade garantida. Mas 
na maior parte das vezes, as pessoas não sabem cada detalhe do que eles esperam de 
um grande projeto. Quanto maior e mais complexo for um projeto, é menos provável 
que seja possível imaginar cada aspecto com detalhes suficientes para se criar uma 
especificação. Esse tipo de processo é um processo em cascata, e essa expressão é 
equivalente a processos ruins praticamente de forma universal nos dias de hoje. 

Então, como os membros da Agile Alliance perceberam, seguir um processo rí- 
gido como a maioria das organizações estava fazendo na época, resultava em soft- 
ware bem testado e minuciosamente documentado, o que não era o que os usuários 
queriam. A rebelião foi criar uma família de metodologias ágeis. Eram processos 
de desenvolvimento de software que caminhavam em direção à mudança fácil. Me- 
nos tempo era gasto fazendo o planejamento e o design. Software é maleável, então 
mudá-lo pode ser barato. As metodologias ágeis pressupunham as mudanças como 
uma parte constante do desenvolvimento, e adaptavam-se para torná-las o mais ba- 
rato e fácil possível. 

Tudo isso parece óbvio agora. Mas naquela época, a adoção de processos ágeis 
era um motivo de conflito e debate. Em tese, a ideia de planejar com detalhe e rigor 
parece obviamente correta. Mas na prática, isso não funciona. 

No início da minha própria conversão às metodologias ágeis (especialmente Ex- 
treme Programming), passei a ver tudo através das lentes do desenvolvimento ágil. 
As forças e as motivações em jogo vieram a ser mais gerais do que para apenas desen- 
volvimento de software. Toda vez que eu tinha que resolver um problema complexo, 
eu percebia que uma abordagem iterativa e receptiva a mudanças era um jeito menos 
estressante e mais efetivo para mim. 

De alguma forma, contudo, levou-me bastante tempo para perceber que o pro- 
jeto mais complexo com que já tive de lidar — o mais estressante e mais crítico — era 
minha carreira. Eu tinha projetado minha carreira do começo ao fim como um pro- 
jeto de software com modelo em cascata. E os mesmos problemas que ocorriam em 
projetos de software estavam começando a acontecer comigo e com minha carreira. 

Eu estava na trilha para ser um vice-presidente bem sucedido, ou um diretor 
de informática. Estava indo muito bem nesse caminho. Eu havia progredido rapi- 
damente de um programador novato para um arquiteto de software, até gerente e 
diretor, e podia facilmente me ver continuando na cadeia. Mas, por mais bem suce- 
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dido que eu fosse, comecei a sentir que estava fazendo um trabalho de que eu náo 
gostava. De fato, quanto mais bem sucedido que eu era, era menos provável que eu 
estivesse em um emprego de que gostasse. 

O que eu estava fazendo comigo era a mesma coisa que processos rígido fa- 
zia com seus clientes. Eu estava fazendo um trabalho excelente de entregar a mim 
mesmo uma carreira que eu náo queria. 

Não era intuitivo para mim no começo, mas a solução para tal problema era 
simplesmente mudar de carreira. Isso pode ter vários significados. Para mim, signi- 
ficava voltar a tecnologia crua que me deixara tao excitado com a indústria de TI em 
primeira instáncia. Para outras pessoas, o significado foi mudar de administracäo de 
sistema para desenvolvimento de software, ou mudar de um campo náo relacionado 
à computação para programação, ou mesmo largar toda a profissão e fazer qualquer 
outra coisa que ama. 

Assim como em desenvolvimento de software, o custo da mudança não precisa 
ser alto. É claro, pode ser difícil mudar de testador de software para advocacia. Mas 
mudar seu caminho de gerência para programação, ou vice-versa, não é difícil. Tam- 
pouco é encontrar uma nova empresa para a qual trabalhar. Ou mudar de cidade. 

E ao contrário de, digamos, construir um arranha-céu, mudar sua carreira não 
requer que você jogue fora tudo que você já fez. Eu fiquei programando em Ruby até 
agora, mas minha experiência como gerente, ou a criação de uma operação de de- 
senvolvimento offshore, são constantemente relevantes e prestativas no que eu faço. 
Meus empregadores e clientes entendem isso e tiram proveito. 

É importante perceber que mudanças não são apenas possíveis em sua carreira, 
como são necessárias. Como um desenvolvedor de software, você nunca gostaria 
de desenvolver algo que seu cliente não quer. Metodologias ágeis ajudam a prevenir 
isso. O mesmo é válido para sua carreira. Determine grande objetivos, mas faça 
correções constantes ao longo do caminho. Aprenda com a experiência, e modifique 
as metas conforme você avança. Em última instância, um cliente feliz é o que todos 
queremos (especialmente quando, na medida em que planejamos nossas carreiras, 
somos os nossos próprios clientes) — não um requerimento completo. 
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Melhor que ontem 


Consertar um erro é (geralmente) fácil. Algo está quebrado, porque alguém relatou. 
Se vocé consegue reproduzir o erro, entáo consertar um erro significa corrigir qual- 
quer mau funcionamento que o causou e verificar que ele nao é mais reproduzivel. 
Se ao menos todos os problemas fossem táo simples! 

Mas nem todo problema ou desafio é táo discreto. A maioria dos desafios im- 
portantes na vida se manifestam como grandes e intransponíveis gotas amorfas de 
fracasso em potencial. Isso é verdade em desenvolvimento de software, gerencia- 
mento de carreira, e até estilo de vida e saúde. 

Um sistema complexo e cheio de erros precisa ser revisto. Sua carreira está es- 
tagnando a cada minuto. Vocé está passivamente deixando que seu estilo de vida 
de programador sedentário baseado em uma escrivaninha transforme seu corpo em 
uma desordem. Todos esses problemas sáo muito maiores e mais difíceis de serem 
simplesmente consertados do que um bug. Eles sáo complexos, difíceis de medir, e 
compostos de múltiplas soluções pequenas e diferentes, algumas das quais vão fra- 
cassar! 


Casa do Código 





Devido a essa complexidade, nós facilmente nos desmotivamos para as grandes 
questões e, em vez disso, viramos nossa atenção a coisas que são mais fáceis de se 
medir e mais rápidas de se consertar. Eis porque procrastinamos. E procrastinação 
gera culpa, o que faz com que nos sintamos mal e, portanto, procrastinemos um 
pouco mais. 

Como eu mencionei em 49, eu tenho lutado para me manter em forma desde 
que me posso me lembrar. De fato, quando você está miseravelmente fora de forma, 
“Simplesmente entre em forma” não é um conceito que você pode sequer compre- 
ender, muito menos fazer algo concreto a respeito disso. Para dificultar, se você fi- 
zer algo para melhorá-lo, você não vai conseguir notar imediatamente, ou mesmo 
passada uma semana, que algo mudou. Aliás, pode ser que você passe todo o dia 
treinando para entrar em forma, e uma semana depois você não tenha mais nada a 
oferecer. 

Esse é o tipo de desmotivador que pode pular na sua frente e o derrotar antes 
mesmo de você começar. 

Eu tenho trabalhado seriamente nesse problema. Ir à academia quase diaria- 
mente, alimentar-me melhor. Mas mesmo quando estou levando o programa a sério, 
é difícil ver os resultados. 

Enquanto eu estava chafurdado em minha desmotivação uma tarde dessas, meu 
amigo Erik Kastner postou uma mensagem no Twitter, com o seguinte texto: 

Ajude-me a entrar em forma... pergunte-me uma vez por dia: “Hoje foi melhor que 
ontem?” (nutrição / exercício) - hoje: SIM! 

Quando li isso, percebi que esse era o ingresso para entrar em forma. Eu o reco- 
nheci dos grandes problemas que eu resolvi com sucesso em minha vida. O segredo 
é focar em fazer o que quer que você esteja tentando ficar melhor hoje do que era on- 
tem. É isso. É fácil. E, assim como Erik estava, é possível sentir entusiasmo quando 
se dá passos reais e tangíveis em direção a uma meta distante. 

Eu também estive recentemente trabalhando em uma das aplicações Ruby on 
Rails mais complexas e feias que já vi. Minha empresa a herdou de outro desen- 
volvedor como um projeto de consultoria. Havia poucas características chave que 
precisavam ser implementadas e uma enorme quantidade de bugs e questões de per- 
formance para serem corrigidas. Quando abrimos o capô para realizar essas mu- 
danças, descobrimos uma gigantesca bagunça. A empresa estava com restrições de 
tempo e dinheiro, então não tínhamos o luxo de começar do zero, mesmo que aquilo 
sendo o clássico tipo de código que te dá vontade de jogar fora. 


Portanto, fizemos pequenas correções após pequenas correções, levando muito 
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mais tempo para terminar cada uma do que era esperado. Quando comecamos, pare- 
cia que a monstruosidade da base do código nunca ia se dissipar. Trabalhar naquela 
aplicação era cansativo e chato. Mas com o tempo, as correções se tornaram mais 
rápidas, e a performance antes inaceitável da aplicação havia melhorado. Isso acon- 
teceu porque nós tomamos a decisáo de tornar a base do código cada dia melhor do 
que era no dia anterior. Algumas vezes, isso significava refatorar um longo método 
em vários menores e mais organizados. Ás vezes, significava remover hierarquias de 
heranga que nunca pertenceram ao modelo de objetos. Outras vezes, simplesmente 
significava consertar um teste de unidade bastante quebrado. 

Porém, desde que fizemos essas mudangas de forma incremental, elas vieram “de 
graça” Refatorar um método é algo que você poderia fazer enquanto você estava to- 
mando uma xícara de café ou conversando com um colega sobre as últimas notícias. 
E fazer uma pequena melhoria é motivador. Você pode claramente ver a diferença 
nessa pequena coisa que você consertou, tão logo quanto a mudança foi feita. 

Mas talvez você não consiga ver uma diferença notável no total com cada mu- 
dança incremental. Quando você está tentando se tornar mais respeitado em seu 
lugar de trabalho, ou ser mais saudável, as melhorias individuais que você realiza 
cada dia frequentemente não apontam diretamente para resultados tangíveis. Essa 
é, como vimos antes, a razão pela qual grandes metas como essas se tornam tão des- 
motivantes. Portanto, para a maioria dos objetivos grandes e difíceis pelos quais você 
está lutando, é importante pensar não tanto em se aproximar à meta cada dia, mas 
sim pensar em sair-se melhor em seus esforços do que ontem. Eu não posso, por 
exemplo, garantir que serei menos gordo hoje do que ontem, mas eu posso contro- 
lar se eu estou fazendo mais hoje para perder peso. E se eu o fizer, tenho o direito de 
me sentir bem com o que fiz. Essas melhorias consistentes e mensuráveis em minhas 
ações me liberta do ciclo de culpa e procrastinação que geralmente derrota muitos 
de nós quando tentamos fazer as Coisas Mais Importantes. 

Você também precisa se sentir feliz com pequenas quantidades de “melhor”. Es- 
crever um teste a mais do que você fez ontem é suficiente para aproximá-lo mais 
ao objetivo de “ser melhor em teste de unidade”. Se você está começando do zero, 
um teste adicional por dia é uma taxa sustentável, e quando chegar o momento em 
que você não consegue mais fazer melhor que ontem, você descobrirá que você já se 
tornou “melhor em teste de unidade” e que não precisa mais continuar fazendo as 
mesmas melhorias. Se, por outro lado, você decidiu partir do zero em direção a 50 
testes no primeiro dia de seu plano, o primeiro dia será difícil e o segundo provavel- 
mente não acontecerá. Portanto, faça suas melhorias pequenas e incrementais, mas, 
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sobretudo, diariamente. Pequenas mudangas também diminuem o preco da falha. 
Se vocé perder um dia, vocé terá uma nova base para amanhá. 

Uma das melhores coisas sobre essa simples máxima é que vocé pode aplicá-la 
para metas muito táticas, tais como terminar um projeto ou melhorar um trecho do 
programa. 

Como vocé agiu melhor hoje para melhorar sua carreira do que vocé fez ontem? 
Faga mais um contato, submeta um patch a um projeto open source, escreva um 
post bem pensado e o publique em seu blog. Ajude mais uma pessoa em um fórum 
técnico de sua área, do que vocé fez ontem. Se todo dia vocé fizer algo um pouco 
melhor do que ontem para melhorar a si mesmo, vocé descobrirá que o que era uma 
distáncia oceánica para construir uma carreira notável se tornou mais palpável. 


Faca algo 


1) Faga uma lista de melhorias complexas e difíceis que vocé gostaria de realizar; 
podem ser tanto de ámbito pessoal como profissional. Está tudo bem se vocé tem 
uma lista razoavelmente longa. Agora, para cada item da lista, pense sobre o que 
vocé poderia fazer hoje para melhorar ou fazer aquele item melhor que ontem. 
Amanhä, olhe para a lista de novo. Ontem foi melhor do que o dia anterior? 
Como vocé pode fazer hoje melhor? Faga o mesmo no próximo dia. Coloque 
isso em seu calendário. Use dois minutos pensando sobre isso cada manhä. 
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Seja independente 


Em momentos de estresse, eu geralmente olho para os meus dias em uma grande em- 
presa. Eu estava táo encaixadinho no meu próprio escritório, ou cubículo, e em uma 
espessa e macia camada da hierarquia de geréncia. Era uma piada para nós ali, mas 
em uma grande empresa, uma pessoa esperta pode permanece sem necessariamente 
concluir nada. Na maioria dos casos, se um projeto náo se tornar pronto, havia gente 
suficiente dividindo a culpa em camadas suficientes, sendo difícil descobrir onde as 
coisas deram errado. E isso € apenas para as falhas. Se as coisas demorassem mais 
do que deveriam, a complexidade da organização obscurecia as razões a um ponto 
em que ninguém realmente tinha a noção de quanto tempo qualquer projeto deveria 
levar para ficar pronto. 

Então, em um dia em que você não está disposto a realmente pisar no acelerador, 
uma grande empresa lhe concede a oportunidade de sentar-se e, digamos, navegar 
na internet por um tempo. Ou ir para casa mais cedo. Ou tirar um dia de licença. 
Apesar de todas as reclamações que fiz durante minha vida sobre empresas grandes, 
definitivamente havia suas vantagens. 
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O problema € que o manto de seguranga de uma hierarquia corporativa diminui 
sua velocidade. Se vocé consegue se esconder por trás do escudo da mediocridade 
que a maioria das divisöes corporativas impunham, náo há muito incentivo para 
exceder. Mesmo aqueles de nós que sáo geralmente bem intencionados sáo tentados 
pelo oásis paradisíaco do Youtube ou sua coleção favorita de web comics. Se você 
estiver procurando por um, tente http://toothpastefordinner.com. Ri durante horas. 

Nesse sentido, uma grande empresa se torna um lugar maravilhoso para ir e 
semi-aposentar-se se vocé está cansado. Mas se vocé está lutando para ser notá- 
vel (o que vocé está!), uma grande empresa é um lugar difícil para entrar no ritmo 
certo, do mesmo jeito que uma padaria é um lugar ruim para tentar eliminar seus 
pneuzinhos. 

A solução? Seja independente! 

Vocé possui um conjunto de habilidades. Vocé as afiou. Vocé sabe o que vocé 
vale. Tornar-se um alguém independente é um dos testes derradeiros. Vocé náo 
tem burocracia por trás da qual se esconder. Vocé é diretamente encarregado das 
pessoas pagando as contas. A ideia de que você está fornecendo um serviço se torna 
diretamente aparente em tudo o que vocé faz. Náo há equipe com quem dividir a 
culpa quando vocé faz coisas erradas. É somente vocé, seus conhecimentos e sua 
habilidade de executar. 

Tornar-se independente também o força a aprender como fazer marketing de 
si mesmo e, ao mesmo tempo, testar suas escolhas de domínio e tecnologia em que 
focar. Você não pode depender de ser encontrado pelos clientes quando você se torna 
independente, no sentido como era em uma grande empresa, quando o trabalho o 
encontrava. Vocé precisa sair e encontrar seus clientes. Uma vez que vocé os achou, 
vocé precisa convencé-los de que vocé é digno de seu pagamento. 

Vocé também precisa decidir quanto vocé quer cobrar. O que vocé faz custa 50 
por hora? Ou custa 250? 

Como vocé irá pagar suas contas? Como vocé justificará a quantia que vocé vale? 
Vocé realmente vale o tanto que vocé achava que valia? 

Ser independente é difícil. Coloca todas suas habilidades enquanto profissional 
em teste. Vocé talvez náo esteja pronto para isso ainda. A boa notícia é que vocé 
náo precisa percorrer o caminho inteiro. Considere isso como um projeto de desen- 
volvimento pessoal, e coloque-se no mercado em seu tempo livre. Determine uma 
meta de ser contratado e conclua-a com um cliente satisfeito. Trabalhe nisso a noite 
e aos finais de semana (mas por favor, náo trabalhe em seu cubículo, em seu trabalho 
fixo!). Vocé aprenderá muita coisa sem perder sua rede de seguranga. Na pior das hi- 


222 


Casa do Código Capítulo 53. Seja independente 





póteses, vocé trabalhará demais por algumas semanas, falhará em um projeto, e será 
mandado de volta para sua confortável cadeira com uma nova sensacáo de apreciar 
seu emprego. No melhor dos casos, vocé será amplamente bem sucedido, amará o 
trabalho, e se colocará em um novo caminho em direção a uma satisfatória carreira 
e á recompensa financeira. 

O revisor Sammy Larbi sugere outra alternativa para ser independente. Se vocé 
atualmente trabalha para uma grande empresa, considere juntar-se a uma pequena. 
Se vocé trabalha para uma empresa consagrada, tente uma startup. Em uma pequena 
startup, vocé pode tirar o melhor dos dois mundos: um emprego de tempo integral 
com um salário e o desafio de ser colocado contra os problemas de seu negócio, sem 
filtro. 


Curiosidade é um ponto forte 


por Mike Clark 

Meus pais falariam que eu era uma crianga curiosa. Fazia várias perguntas, lia 
tudo que eu tinha em máos, e aprendia como as coisas funcionam desmontando-as. 
Como se vé, isso náo foi apenas uma fase — eu nunca deixei de ter uma curiosidade 
insaciável. É fácil negligenciar, mas acredito que curiosidade pode ser um ponto 
forte. Ás vezes, só é necessário um pouco de prática para desenvolvé-la. 

Olhando para trás, consigo identificar vários eventos que mudaram minha car- 
reira, que ocorreram principalmente porque eu segui uma curiosidade. Aqui oferego 
os seguintes exemplos, na esperanga de que eles o encoragem a escutar quando a cu- 
riosidade chama: 

Eu nunca descobri que viraria um programador. Sempre fui fascinado por avióes 
e naves espaciais, entáo entrar para o programa de engenharia espacial da Embry- 
Riddle Aeronautical University parecia a escolha lógica. Depois de um ano olhando 
por aí, entretanto, descobri que a galera do departamento de Ciéncia da Computa- 
ção estava se divertindo muito mais. Como parte do novo programa de graduação, 
eles estavam aplicando ciência da computação em problemas relacionados à aviação. 
No ensino médio eu havia me tornado curioso sobre computadores, mas nunca re- 
almente tinha considerado programação como uma carreira. Então, comecei a sair 
com os geeks da computação para ver o que eles faziam. Em pouco tempo, eu troquei 
os programas de graduação. Essa mudança por si só acabou sendo uma das minhas 
melhores decisões. Os cursos ainda eram desafiadores, mas eu amava cada minuto. 
Minha curiosidade inicial em programação rapidamente se tornou uma paixão que 
me fez me inscrever em um estágio da NASA e começar minha carreira em software 
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com um grande salto. E até o dia de hoje, eu nunca subestimo a recompensa em po- 
tencial de descobrir em que os companheiros geeks estäo trabalhando por diversáo. 

Toda vez que me sinto confortável, sei que € hora de tentar algo novo. Após mui- 
tos anos escrevendo software embarcado na indústria aeroespacial, eu estava confor- 
tável (o que, para mim, sempre está associado a tédio) com C e C++. Naquela época, 
programacáo web acordou minha curiosidade, principalmente porque era radical- 
mente diferente de programagäo de sistemas embarcados. Infelizmente, o projeto do 
meu emprego náo tinha acesso a web (era um daqueles projetos ultrasecretos), entáo, 
resolvi passar minhas noites e finais de semana aprendendo a escrever software para 
web. Esse interesse lateral eventualmente se tornou uma oportunidade de trabalhar 
em um novo projeto, usando Java. Acabei construindo aplicações web baseadas em 
Java para muitos mais projetos... e empregadores. Minha curiosidade sobre desen- 
volvimento web era o catalisador para diversificar minhas habilidades, o que acabou 
sendo uma boa mudança de carreira. 

Eu aprendi Ruby on Rails por um capricho. Ruby era uma linguagem divertida 
que me fazia pensar diferente sobre programação. Rails fazia o mesmo para as apli- 
cações web. Eu não tinha nenhum cliente naquela época que estava contratando tra- 
balho em Ruby on Rails, mas isso não importava. Eu era curioso, e simplesmente não 
conseguia evitar. Eu peguei as horas menos úteis e usei para me dedicar ao Ruby on 
Rails. Mal sabia eu que no começo de 2005 eu receberia a oportunidade de construir 
uma das primeiras aplicações comerciais Rails e seria convidado po Dave Thomas 
para ajudá-lo em seu livro de Rails. Minha curiosidade sobre outra nova tecnologia 
começou outra curva de sucesso em minha carreira. 

Minha curiosidade vai além da tecnologia; aspectos de negócio são igualmente 
interessantes para mim. Isso me levou a me aventurar por conta própria como um 
consultor independente e a começar uma empresa de treinamento (The Pragmatic 
Studio). Minha curiosidade no funcionamento de uma pequena empresa me deu 
a oportunidade de aprender um monte de novas habilidades: vendas, marketing, 
suporte ao cliente e assim por diante. Ver o grande cenário me ajudou a me tornar 
um programador melhor. 

Então, onde está sua verdadeira curiosidade? Tente seguir seus interesses por 
um tempo, e veja o que acontece. Você pode se surpreender! 


Mike Clark é um programador/consultor independente 
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Divirta-se 


Mas eu vos digo que, quando trabalhais, realizais parte do sonho mais longínquo da 
terra, desempenhando assim uma missáo que vos foi designada quando esse sonho 
nasceu. E, apegando-vos ao trabalho, estareis na verdade amando a vida. E quem 


ama a vida através do trabalho, partilha do segredo mais íntimo da vida. 
- Kalil Gibran, O profeta 


Se você alcançou o ponto de ser um desenvolvedor de software com o luxo de 
realmente pensar sobre qual caminho você quer que sua carreira tome, parabéns! 
Você pode se considerar bastante sortudo. Existem muitas culturas nas quais poder 
decidir o que você faz como profissão é um enorme privilégio que poucas pessoas 
disfrutam. Como um programador, é provável que você não precise se preocupar 
em como pagar por um lugar para viver ou como comprar comida. 

Você poderia ter escolhido dentre inúmeras carreiras, mas esta é excitante. É 
criativa. Requer pensamento profundo e lhe traz como recompensa a sensação de 
conseguir fazer algo que a maioria das pessoas que você encontra todo dia não ima- 
gina que seja possível. Nós nos preocupamos com progredir para o próximo nível, 
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causar um impacto, ou ganhar respeito dos nossos colegas na indústria, mas se vocé 
realmente parar para pensar nisso, nós nos saímos muito bem. 

Desenvolvimento de software é tanto desafiador como recompensador. É cria- 
tivo como uma forma de arte, mas (diferentemente da arte) fornece valor concreto e 
mensuravel. 

Desenvolvimento de software é divertido! 

Por fim, a coisa mais importante que eu aprendi nessa jornada que minha car- 
reira em programação tem sido é que não é o que você faz como profissão, ou o que 
vocé tem, que importa. E como vocé escolhe aceitar essas coisas. E interno. Satisfa- 
ção, como nossa escolha de carreira, é algo que devia ser buscado depois e decidido 
intencionalmente. 


226 


CAPÍTULO 55 


Nota da editora 


A traducao deste livro foi feita por Adriano Almeida e Vivian Matsui. Em caso de dú- 
vidas ou sugestóes, vocé pode entrar em contato com os editores através dos e-mails 
adriano.almeida@casadocodigo.com.br e vivian.matsui@casadocodigo.com.br. 
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